[Rd] website feature request - a roadmap (PR#13589)
Full_Name: Danny Chia Version: 2.8.1 OS: Windows Submission from: (NULL) (169.229.100.137) This is more of a feature request, but it would be nice if the CRAN website had some sort of roadmap for R. That way, users would know what to expect for future versions of R. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] website feature request - a roadmap (PR#13589)
Have you seen developer.r-project.org? All the relevant information is there. For the medium-term (up to 6 months) the NEWS file in the R-devel version of R indicates currently intended changes. CRAN is a distribution network, and distinct from www.r-project.org and developer.r-project.org. The R project does not have staff, and all plans are subject to ther availability of volunteer help. In practice that means that long-term goals are subject to some indefinite delays as the circumstances of individuals change. On Wed, 11 Mar 2009, dannyc...@berkeley.edu wrote: Full_Name: Danny Chia Version: 2.8.1 OS: Windows Submission from: (NULL) (169.229.100.137) This is more of a feature request, but it would be nice if the CRAN website had some sort of roadmap for R. That way, users would know what to expect for future versions of R. -- Brian D. Ripley, rip...@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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] configure fail for XML package on freebsd
Hi,
I am having problems installing the XML package with R-devel on
freebsd. If I simply do install.packages("XML"), it says that the
parser.h file is not found. After reading the INSTALL file, I have set
setenv XML_CONFIG /usr/local/bin/xml2-config
setenv LIBXML_LIBDIR -L/usr/local/lib
setenv LIBXML_INCDIR -I/usr/local/include/libxml2/libxml
and install.packages("XML") fails with
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking for libxml/parser.h... (cached) no
checking for gnome-xml/parser.h... (cached) no
Located parser file -I/usr/local/include/libxml2/libxml/parser.h
checking for gzopen in -lz... yes
checking for xmlParseFile in -lxml2... yes
You are trying to use a version 2.* edition of libxml
but an incompatible library. The header files and library seem to be
mismatched. If you have specified LIBXML_INCDIR, make certain to also
specify an appropriate LIBXML_LIBDIR if the libxml2 library is not in
the default
directories.
ERROR: configuration failed for package 'XML'
* Removing '/usr/local/share/R-devel/library/XML'
Warning in install.packages("XML", clean = TRUE) :
installation of package 'XML' had non-zero exit status
Some version info on my machine:
erdos# portversion -F "libxml*"
libxml2-2.7.3 =
erdos# xml2-config --version
2.7.3
erdos# ls /usr/local/lib/libxml*
/usr/local/lib/libxml2.a /usr/local/lib/libxmlparse.so@
/usr/local/lib/libxml2.la* /usr/local/lib/libxmlparse.so.1*
/usr/local/lib/libxml2.so@ /usr/local/lib/libxmltok.a
/usr/local/lib/libxml2.so.5* /usr/local/lib/libxmltok.la*
/usr/local/lib/libxmlparse.a /usr/local/lib/libxmltok.so@
/usr/local/lib/libxmlparse.la* /usr/local/lib/libxmltok.so.1*
The header LIBXML_INCDIR/xmlversion.h does define version as 2.7.3.
Does anyone have an idea of what may be going wrong?
h.
--
+---
| Hiroyuki Kawakatsu
| Business School, Dublin City University
| Dublin 9, Ireland. Tel +353 (0)1 700 7496
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] configure fail for XML package on freebsd
Hi Hiroyuki
Hiroyuki Kawakatsu wrote:
Hi,
I am having problems installing the XML package with R-devel on
freebsd. If I simply do install.packages("XML"), it says that the
parser.h file is not found. After reading the INSTALL file, I have set
setenv XML_CONFIG /usr/local/bin/xml2-config
setenv LIBXML_LIBDIR -L/usr/local/lib
setenv LIBXML_INCDIR -I/usr/local/include/libxml2/libxml
That should probably be
setenv LIBXML_INCDIR -I/usr/local/include/libxml2
(rather than having the additional /libxml after it.)
Did you install libxml2 version 2.7.3 yourself,
i.e. separately from the installation of the operating system?
Is /usr/local/lib being searched for .so files by your dynamic
loader?
Try
ldd `which xmllint`
to see what shared libraries it finds? Does it list
libxml2.so.2 and if so, where is the file to which it points -
/usr/lib or /usr/local/lib ? If it is /usr/lib, that is the
problem.
If this doesn't identify the problem, please download
the XML_2.3-0.tar.gz file and issue the commands
tar zxf XML_2.3-0.tar.gz
R CMD INSTALL XML
and send me the file XML/config.log and I can try to
find out what is going wrong form the details in that.
Thanks,
D.
and install.packages("XML") fails with
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking for libxml/parser.h... (cached) no
checking for gnome-xml/parser.h... (cached) no
Located parser file -I/usr/local/include/libxml2/libxml/parser.h
checking for gzopen in -lz... yes
checking for xmlParseFile in -lxml2... yes
You are trying to use a version 2.* edition of libxml
but an incompatible library. The header files and library seem to be
mismatched. If you have specified LIBXML_INCDIR, make certain to also
specify an appropriate LIBXML_LIBDIR if the libxml2 library is not in
the default
directories.
ERROR: configuration failed for package 'XML'
* Removing '/usr/local/share/R-devel/library/XML'
Warning in install.packages("XML", clean = TRUE) :
installation of package 'XML' had non-zero exit status
Some version info on my machine:
erdos# portversion -F "libxml*"
libxml2-2.7.3 =
erdos# xml2-config --version
2.7.3
erdos# ls /usr/local/lib/libxml*
/usr/local/lib/libxml2.a /usr/local/lib/libxmlparse.so@
/usr/local/lib/libxml2.la* /usr/local/lib/libxmlparse.so.1*
/usr/local/lib/libxml2.so@ /usr/local/lib/libxmltok.a
/usr/local/lib/libxml2.so.5* /usr/local/lib/libxmltok.la*
/usr/local/lib/libxmlparse.a /usr/local/lib/libxmltok.so@
/usr/local/lib/libxmlparse.la* /usr/local/lib/libxmltok.so.1*
The header LIBXML_INCDIR/xmlversion.h does define version as 2.7.3.
Does anyone have an idea of what may be going wrong?
h.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Could you please add "time<-" as a generic function in the 'stats' package ?
Dear R developers,
As you might have noticed, recent changes in R-dev will not allow the
definition of S3 methods with S4 classes.
But until now, we have defined "time<-" in our 'timeSeries' package as
an S3 generic because other packages are using the same function.
Indeed, if we had defined it as an S4 generic, the other packages
would not coexist well with ours.
Another package might overwrite the generic and its methods when both
packages are loaded.
In my understanding the only way to avoid this problem is to add
`time<-`
function (x, value)
{
UseMethod("time<-")
}
in the 'stats' package.
As a wish for the forthcoming R version I would like to ask you if you
could add "time<-" as a generic function in the 'stats' package to
prevent conflicts and to ensure that packages continue to work well
together.
Thank you in advance for your feedback!
--
PhD student
Swiss Federal Institute of Technology
Zurich
www.ethz.ch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] configure fail for XML package on freebsd
On 3/11/09, Duncan Temple Lang wrote: [...] > > That should probably be > setenv LIBXML_INCDIR -I/usr/local/include/libxml2 > > (rather than having the additional /libxml after it.) OK, thanks. But this still fails. > Did you install libxml2 version 2.7.3 yourself, > i.e. separately from the installation of the operating system? I did not install myself. It must have been installed as dependency of some other package. > Is /usr/local/lib being searched for .so files by your dynamic > loader? > > Try > > ldd `which xmllint` > > to see what shared libraries it finds? Does it list > libxml2.so.2 and if so, where is the file to which it points - > /usr/lib or /usr/local/lib ? If it is /usr/lib, that is the > problem. erdos# ldd `which xmllint` /usr/local/bin/xmllint: libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x80063e000) libz.so.4 => /lib/libz.so.4 (0x800884000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x800998000) libm.so.5 => /lib/libm.so.5 (0x800b91000) libc.so.7 => /lib/libc.so.7 (0x800cab000) > If this doesn't identify the problem, please download > the XML_2.3-0.tar.gz file and issue the commands > > tar zxf XML_2.3-0.tar.gz > R CMD INSTALL XML > > and send me the file XML/config.log and I can try to > find out what is going wrong form the details in that. [...] Aha, thanks for the hint. Once I checked the config.log file, I found the source of the error. XML was using a different version of gcc than that used from building R-devel. So the solution was simply to do R CMD INSTALL --configure-vars="MAKE=gmake CC=gcc44 ..." XML Thanks very much for your help. Is there a way to automagically use the configure-vars used to build R for any package installs without having to explicitly pass them as above? h. -- +--- | Hiroyuki Kawakatsu | Business School, Dublin City University | Dublin 9, Ireland. Tel +353 (0)1 700 7496 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] configure fail for XML package on freebsd
I would like to write an S4 generic for 'median', but I am not sure
how to do this properly as the function does not have a "..." argument
I can do this
setGeneric("median", function(x, na.rm=FALSE)
standardGeneric("median"))
but I want to be able to pass it a number of objects of the same
class, so I need a ... argument; or use signature='list' which is not
very useful.
I can do this:
setGeneric("median", function(x, ..., na.rm=FALSE)
standardGeneric("median"))
and
setMethod('median', signature(x='ANY'),
function(x, ..., na.rm=FALSE){ x <- c(x, ...)
return(stats::median(x, na.rm=na.rm))
# }
#)
setMethod("median", signature(x='Raster'),
function(x, ..., na.rm=FALSE){
# rasters <- list(...)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] generic method for median
Sorry, I pressed the wrong button (tab in gmail is tricky) , here is
my message again, now more complete, and with the right subject:
I would like to write an S4 generic for 'median', but I am not sure
how to do this properly as the function does not have a "..." argument
I can do this
setGeneric("median", function(x, na.rm=FALSE)
standardGeneric("median"))
but I want to be able to pass it a number of objects of the same
class, so I need a ... argument; or use signature='list' which is not
very useful.
I can do this:
setGeneric("median", function(x, ..., na.rm=FALSE)
standardGeneric("median"))
and
setMethod('median', signature(x='ANY'),
function(x, ..., na.rm=FALSE){ x <- c(x, ...)
return(stats::median(x, na.rm=na.rm)) } )
and
setMethod("median", signature(x='Raster'),
function(x, ..., na.rm=FALSE){
})
etcetera,
but that gives an ugly message at startup about my package hiding
median from stats.
Is there a solution for this, or does the stats::median function need
to be changed?
Thanks, Robert
> # rasters <- list(...)
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names<-
Wacek,
Peter gave you a full answer explaining it very well. If you really
want to be able to trace each instance yourself, you have to learn far
more about R internals than you apparently know (and Peter hinted at
that). Internally x=1 an x=c(1) are slightly different in that the
former has NAMED(x) = 2 whereas the latter has NAMED(x) = 0 which is
what causes the difference in behavior as Peter explained. The reason
is that c(1) creates a copy of the 1 (which is a constant [=unmutable]
thus requiring a copy) and the new copy has no other references and
thus can be modified and hence NAMED(x) = 0.
Cheers,
Simon
On Mar 10, 2009, at 18:16 , Wacek Kusnierczyk wrote:
i got an offline response saying that my original post may have not
been
clear as to what the problem was, essentially, and that i may need to
restate it in words, in addition to code.
the problem is: the performance of 'names<-' is incoherent, in that
in
some situations it acts in a functional manner, producing a copy of
its
argument with the names changed, while in others it changes the object
in-place (and returns it), without copying first. your explanation
below is of course valid, but does not seem to address the issue. in
the examples below, there is always (or so it seems) just one
reference
to the object.
why are the following functional:
x = 1; 'names<-'(x, 'foo'); names(x)
x = 'foo'; 'names<-'(x, 'foo'); names(x)
while these are destructive:
x = c(1); 'names<-'(x, 'foo'); names(x)
x = c('foo'); 'names<-'(x, 'foo'); names(x)
it is claimed that in r a singular value is a one-element vector, and
indeed,
identical(1, c(1))
# TRUE
all.equal(is(1), is(c(1)))
# TRUE
i also do not understand the difference here:
x = c(1); 'names<-'(x, 'foo'); names(x)
# "foo"
x = c(1); names(x); 'names<-'(x, 'foo'); names(x)
# "foo"
x = c(1); print(x); 'names<-'(x, 'foo'); names(x)
# NULL
x = c(1); print(c(x)); 'names<-'(x, 'foo'); names(x)
# "foo"
does print, but not names, increase the reference count for x when
applied to x, but not to c(x)?
if the issue is that there is, in those examples where x is left
unchanged, an additional reference to x that causes the value of x
to be
copied, could you please explain how and when this additional
reference
is created?
thanks,
vQ
Peter Dalgaard wrote:
is there something i misunderstand here?
Only the ideology/pragmatism... In principle, R has call-by-value
semantics and a function does not destructively modify its
arguments(*),
and foo(x)<-bar behaves like x <- "foo<-"(x, bar). HOWEVER, this has
obvious performance repercussions (think x <- rnorm(1e7); x[1] <-
0), so
we do allow destructive modification by replacement functions,
PROVIDED
that the x is not used by anything else. On the least suspicion that
something else is using the object, a copy of x is made before the
modification.
So
(A) you should not use code like y <- "foo<-"(x, bar)
because
(B) you cannot (easily) predict whether or not x will be modified
destructively
(*) unless you mess with match.call() or substitute() and the like.
But
that's a different story.
--
---
Wacek Kusnierczyk, MD PhD
Email: w...@idi.ntnu.no
Phone: +47 73591875, +47 72574609
Department of Computer and Information Science (IDI)
Faculty of Information Technology, Mathematics and Electrical
Engineering (IME)
Norwegian University of Science and Technology (NTNU)
Sem Saelands vei 7, 7491 Trondheim, Norway
Room itv303
Bioinformatics & Gene Regulation Group
Department of Cancer Research and Molecular Medicine (IKM)
Faculty of Medicine (DMF)
Norwegian University of Science and Technology (NTNU)
Laboratory Center, Erling Skjalgsons gt. 1, 7030 Trondheim, Norway
Room 231.05.060
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names<-
On Mar 11, 2009, at 10:52 , Simon Urbanek wrote:
Wacek,
Peter gave you a full answer explaining it very well. If you really
want to be able to trace each instance yourself, you have to learn
far more about R internals than you apparently know (and Peter
hinted at that). Internally x=1 an x=c(1) are slightly different in
that the former has NAMED(x) = 2 whereas the latter has NAMED(x) = 0
which is what causes the difference in behavior as Peter explained.
The reason is that c(1) creates a copy of the 1 (which is a constant
[=unmutable] thus requiring a copy) and the new copy has no other
references and thus can be modified and hence NAMED(x) = 0.
Errata: to be precise replace NAMED(x) = 0 with NAMED(x) = 1 above --
since NAMED(c(1)) = 0 and once it's assigned to x it becomes NAMED(x)
= 1 -- this is just a detail on how things work with assignment, the
explanation above is still correct since duplication happens
conditional on NAMED == 2.
Cheers,
Simon
On Mar 10, 2009, at 18:16 , Wacek Kusnierczyk wrote:
i got an offline response saying that my original post may have not
been
clear as to what the problem was, essentially, and that i may need to
restate it in words, in addition to code.
the problem is: the performance of 'names<-' is incoherent, in
that in
some situations it acts in a functional manner, producing a copy of
its
argument with the names changed, while in others it changes the
object
in-place (and returns it), without copying first. your explanation
below is of course valid, but does not seem to address the issue. in
the examples below, there is always (or so it seems) just one
reference
to the object.
why are the following functional:
x = 1; 'names<-'(x, 'foo'); names(x)
x = 'foo'; 'names<-'(x, 'foo'); names(x)
while these are destructive:
x = c(1); 'names<-'(x, 'foo'); names(x)
x = c('foo'); 'names<-'(x, 'foo'); names(x)
it is claimed that in r a singular value is a one-element vector, and
indeed,
identical(1, c(1))
# TRUE
all.equal(is(1), is(c(1)))
# TRUE
i also do not understand the difference here:
x = c(1); 'names<-'(x, 'foo'); names(x)
# "foo"
x = c(1); names(x); 'names<-'(x, 'foo'); names(x)
# "foo"
x = c(1); print(x); 'names<-'(x, 'foo'); names(x)
# NULL
x = c(1); print(c(x)); 'names<-'(x, 'foo'); names(x)
# "foo"
does print, but not names, increase the reference count for x when
applied to x, but not to c(x)?
if the issue is that there is, in those examples where x is left
unchanged, an additional reference to x that causes the value of x
to be
copied, could you please explain how and when this additional
reference
is created?
thanks,
vQ
Peter Dalgaard wrote:
is there something i misunderstand here?
Only the ideology/pragmatism... In principle, R has call-by-value
semantics and a function does not destructively modify its
arguments(*),
and foo(x)<-bar behaves like x <- "foo<-"(x, bar). HOWEVER, this has
obvious performance repercussions (think x <- rnorm(1e7); x[1] <-
0), so
we do allow destructive modification by replacement functions,
PROVIDED
that the x is not used by anything else. On the least suspicion that
something else is using the object, a copy of x is made before the
modification.
So
(A) you should not use code like y <- "foo<-"(x, bar)
because
(B) you cannot (easily) predict whether or not x will be modified
destructively
(*) unless you mess with match.call() or substitute() and the
like. But
that's a different story.
--
---
Wacek Kusnierczyk, MD PhD
Email: w...@idi.ntnu.no
Phone: +47 73591875, +47 72574609
Department of Computer and Information Science (IDI)
Faculty of Information Technology, Mathematics and Electrical
Engineering (IME)
Norwegian University of Science and Technology (NTNU)
Sem Saelands vei 7, 7491 Trondheim, Norway
Room itv303
Bioinformatics & Gene Regulation Group
Department of Cancer Research and Molecular Medicine (IKM)
Faculty of Medicine (DMF)
Norwegian University of Science and Technology (NTNU)
Laboratory Center, Erling Skjalgsons gt. 1, 7030 Trondheim, Norway
Room 231.05.060
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] E`<`
Looks like an infinite recursion in R_isMissing, which I think may be turned into an infinite loop if the C compiler is doing tail call optimization. I need to understand why this is written the way it is and also why another case that I would expect to also have this problem does not before identifying the appropriate fix. luke On Tue, 10 Mar 2009, Peter Dalgaard wrote: Stavros Macrakis wrote: Tested in: R version 2.8.1 (2008-12-22) / Windows Recursive default argument references normally give nice clear errors. In the first set of examples, you get the error: Error in ... : promise already under evaluation: recursive default argument reference or earlier problems? (function(a = a) a ) () (function(a = a) c(a) ) () (function(a = a) a[1] ) () (function(a = a) a[[1]] ) () (function(a = a) a$x) () (function(a = a) mean(a) ) () (function(a = a) sort(a) ) () (function(a = a) as.list(a) ) () But in the following examples, R seems not to detect the 'promise already under evaluation' condition and instead gets a stack overflow, with the error message: Error: C stack usage is too close to the limit (function(a = a) (a)) () (function(a = a) -a ) () (function(a = a) var(a) ) () (function(a = a) sum(a) ) () (function(a = a) is.vector(a) ) () (function(a = a) as.numeric(a) ) () I don't understand why the two sets of examples behave differently. Ouch!!! This shouldn't happen, I'm pretty sure. In particular not the apparently unstoppable loop under Linux. Thanks for pointing it out. -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: l...@stat.uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Could you please add "time<-" as a generic function in the 'stats' package ?
Whatever one wants for an S3 generic, it's not needed to do what,
presumably, you want here.
And for sure it is no excuse for S3 methods for S4 classes.
Back to basics: To write S4 methods for an existing function, the clean
and simple way is usually:
setGeneric("time<-")
If your package depends on one that has S3 methods for this function,
there will be a version of the function imported into your namespace.
That function will then be the default method.
Presumably you want to ensure that S3 methods, for S3 classes, are still
dispatched. Quite reasonable and it should follow from the call to
setGeneric.
If you wanted to have your own S3 methods or if you weren't willing to
assume an S3 generic imported, you could do a 2-line version:
R(r48103)> `time<-` <- function(x, value) UseMethod("time<-")
R(r48103)> setGeneric("time<-")
[1] "time<-"
R(r48103)> showMethods("time<-", include = TRUE)
Function: time<- (package .GlobalEnv)
x="ANY"
function (x, value)
UseMethod("time<-")
As a postscript, here is the current plan, not yet committed, pending
some more testing:
- the bad methods will be allowed
- warnings when a class is defined with such methods for a superclass
- probably some other warnings, but not for an ordinary call to the
method (it's the MISSING calls to the method that are the disaster).
More later,
John
Yohan Chalabi wrote:
Dear R developers,
As you might have noticed, recent changes in R-dev will not allow the
definition of S3 methods with S4 classes.
But until now, we have defined "time<-" in our 'timeSeries' package as
an S3 generic because other packages are using the same function.
Indeed, if we had defined it as an S4 generic, the other packages
would not coexist well with ours.
Another package might overwrite the generic and its methods when both
packages are loaded.
In my understanding the only way to avoid this problem is to add
`time<-`
function (x, value)
{
UseMethod("time<-")
}
in the 'stats' package.
As a wish for the forthcoming R version I would like to ask you if you
could add "time<-" as a generic function in the 'stats' package to
prevent conflicts and to ensure that packages continue to work well
together.
Thank you in advance for your feedback!
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Compiling R-2.8.1 on Sparc Solaris 10: libRlapack.so: symbol __vlog_: referenced symbol not found
Hi, I am compiling R2.8.1 on a Sun M4000 machine with Solaris 10. I am using Sun Studio 12. I get the following error: cc -xtarget=native64 -G -L/usr/sfw/lib/sparcv9 -L/opt/csw/lib/sparcv9 -o grDevices.so chull.o devNull.o devPicTeX.o devPS.o devQuartz.o init.o mkdir ../../../../library/grDevices/libs Warning in solve.default(rgb) : unable to load shared library '/export/admin-home/nikser/R-2.8.1/modules//lapack.so': ld.so.1: R: fatal: relocation error: file /export/admin-home/nikser/R-2.8.1/lib/libRlapack.so: symbol __vlog_: referenced symbol not found Error in solve.default(rgb) : lapack routines cannot be loaded Error: unable to load R code in package 'grDevices' Execution halted *** Error code 1 The following command caused the error: echo "tools:::makeLazyLoading(\"grDevices\")" | \ R_DEFAULT_PACKAGES=NULL LC_ALL=C ../../../bin/R --vanilla --slave > /dev/null make: Fatal error: Command failed for target `all' Current working directory /export/admin-home/nikser/R-2.8.1/src/library/grDevices I set the following environment variables: export LDFLAGS="-L/usr/sfw/lib/sparcv9 -L/opt/csw/lib/sparcv9" export CFLAGS="-I/usr/sfw/include -I/opt/csw/include" export R_PAPERSIZE=letter export CC="cc -xtarget=native64" export FC="f95 -xtarget=native64" export CXX="CC -xtarget=native64" export CPPFLAGS="-I/usr/sfw/include -I/opt/csw/include" export CFLAGS="-O -xlibmieee" export F77="f95 -xtarget=native64" export CXXFLAGS=-O export FFLAGS="-O4 -xlibmopt -libmil -xvector=lib -fround=nearest" export FCFLAGS=$FFLAGS export LDFLAGS="-L/usr/sfw/lib/sparcv9 -L/opt/csw/lib/sparcv9" export SHLIB_CXXLDFLAGS="-G -lCstd" export BLAS_LIBS=-xlic_lib=sunperf export LIBS="-lmvec" export SHLIB_CFLAGS=-lmvec and: ./configure --prefix=/opt/R-2.8.1 --enable-threads=solaris --with-blas Could you please help me to pinpoint the problem. Thanks -- Mohammad __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling R-2.8.1 on Sparc Solaris 10: libRlapack.so: symbol __vlog_: referenced symbol not found
Please try the options recommended in the R-admin manual: these do not include using sunperf. But if you want to choose your own options, ask your local Solaris help as this is not an R issue. On Wed, 11 Mar 2009, Mohammad Nikseresht wrote: Hi, I am compiling R2.8.1 on a Sun M4000 machine with Solaris 10. I am using Sun Studio 12. I get the following error: cc -xtarget=native64 -G -L/usr/sfw/lib/sparcv9 -L/opt/csw/lib/sparcv9 -o grDevices.so chull.o devNull.o devPicTeX.o devPS.o devQuartz.o init.o mkdir ../../../../library/grDevices/libs Warning in solve.default(rgb) : unable to load shared library '/export/admin-home/nikser/R-2.8.1/modules//lapack.so': ld.so.1: R: fatal: relocation error: file /export/admin-home/nikser/R-2.8.1/lib/libRlapack.so: symbol __vlog_: referenced symbol not found Error in solve.default(rgb) : lapack routines cannot be loaded Error: unable to load R code in package 'grDevices' Execution halted *** Error code 1 The following command caused the error: echo "tools:::makeLazyLoading(\"grDevices\")" | \ R_DEFAULT_PACKAGES=NULL LC_ALL=C ../../../bin/R --vanilla --slave > /dev/null make: Fatal error: Command failed for target `all' Current working directory /export/admin-home/nikser/R-2.8.1/src/library/grDevices I set the following environment variables: export LDFLAGS="-L/usr/sfw/lib/sparcv9 -L/opt/csw/lib/sparcv9" export CFLAGS="-I/usr/sfw/include -I/opt/csw/include" export R_PAPERSIZE=letter export CC="cc -xtarget=native64" export FC="f95 -xtarget=native64" export CXX="CC -xtarget=native64" export CPPFLAGS="-I/usr/sfw/include -I/opt/csw/include" export CFLAGS="-O -xlibmieee" export F77="f95 -xtarget=native64" export CXXFLAGS=-O export FFLAGS="-O4 -xlibmopt -libmil -xvector=lib -fround=nearest" export FCFLAGS=$FFLAGS export LDFLAGS="-L/usr/sfw/lib/sparcv9 -L/opt/csw/lib/sparcv9" export SHLIB_CXXLDFLAGS="-G -lCstd" export BLAS_LIBS=-xlic_lib=sunperf export LIBS="-lmvec" export SHLIB_CFLAGS=-lmvec and: ./configure --prefix=/opt/R-2.8.1 --enable-threads=solaris --with-blas Could you please help me to pinpoint the problem. Thanks -- Mohammad __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names<-
Simon Urbanek wrote: > Wacek, > > Peter gave you a full answer explaining it very well. If you really > want to be able to trace each instance yourself, you have to learn far > more about R internals than you apparently know (and Peter hinted at > that). Internally x=1 an x=c(1) are slightly different in that the > former has NAMED(x) = 2 whereas the latter has NAMED(x) = 0 which is > what causes the difference in behavior as Peter explained. The reason > is that c(1) creates a copy of the 1 (which is a constant [=unmutable] > thus requiring a copy) and the new copy has no other references and > thus can be modified and hence NAMED(x) = 0. simon, thanks for the explanation, it's now as clear as i might expect. now i'm concerned with what you say: that to understand something visible to the user one needs to "learn far more about R internals than one apparently knows". your response suggests that to use r without confusion one needs to know the internals, and this would be a really bad thing to say.. i have long been concerned with that r unnecessarily exposes users to its internals, and here's one more example of how the interface fails to hide the guts. (and peter did not give me a full answer, but a vague hint.) vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names<-
Simon Urbanek wrote: > > On Mar 11, 2009, at 10:52 , Simon Urbanek wrote: > >> Wacek, >> >> Peter gave you a full answer explaining it very well. If you really >> want to be able to trace each instance yourself, you have to learn >> far more about R internals than you apparently know (and Peter hinted >> at that). Internally x=1 an x=c(1) are slightly different in that the >> former has NAMED(x) = 2 whereas the latter has NAMED(x) = 0 which is >> what causes the difference in behavior as Peter explained. The reason >> is that c(1) creates a copy of the 1 (which is a constant >> [=unmutable] thus requiring a copy) and the new copy has no other >> references and thus can be modified and hence NAMED(x) = 0. >> > > Errata: to be precise replace NAMED(x) = 0 with NAMED(x) = 1 above -- > since NAMED(c(1)) = 0 and once it's assigned to x it becomes NAMED(x) > = 1 -- this is just a detail on how things work with assignment, the > explanation above is still correct since duplication happens > conditional on NAMED == 2. i guess this is what every user needs to know to understand the behaviour one can observe on the surface? thanks for further clarifications. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building R for Vistax64
Hi all, I have successfully built from source the 32-bit version of R on my Vista 64-bit box. I was hoping to graduate to a 64-bit version so I could analyze some larger data sets. I have 8gb RAM installed. I downloaded the latest 64-bit versions of Perl and MinGW but wasn't sure how to edit the source code to have it build using the 64-bit versions. I did change my PATH variable to point to the bin directories of the 64-bit Perl and MinGW packages. Any pointers would be very helpful. Thanks, Fraser Fraser Sim, PhD Assistant Professor of Neurology & Neurosurgery University of Rochester [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Could you please add "time<-" as a generic function in the 'stats' package ?
"JC" == John Chambers
on Wed, 11 Mar 2009 09:57:43 -0700
JC> Whatever one wants for an S3 generic, it's not needed to do what,
JC> presumably, you want here.
JC>
JC> And for sure it is no excuse for S3 methods for S4 classes.
JC>
JC> Back to basics: To write S4 methods for an existing function, the clean
JC> and simple way is usually:
JC>
JC> setGeneric("time<-")
JC>
JC> If your package depends on one that has S3 methods for this function,
JC> there will be a version of the function imported into your namespace.
JC> That function will then be the default method.
JC>
JC> Presumably you want to ensure that S3 methods, for S3 classes, are still
JC> dispatched. Quite reasonable and it should follow from the call to
JC> setGeneric.
JC>
JC> If you wanted to have your own S3 methods or if you weren't willing to
JC> assume an S3 generic imported, you could do a 2-line version:
JC>
JC> R(r48103)> `time<-` <- function(x, value) UseMethod("time<-")
JC> R(r48103)> setGeneric("time<-")
JC> [1] "time<-"
JC> R(r48103)> showMethods("time<-", include = TRUE)
JC> Function: time<- (package .GlobalEnv)
JC> x="ANY"
JC> function (x, value)
JC> UseMethod("time<-")
In my opinion you example only works in '.GlobalEnv' environement, but
does not work when implemented in a package.
I wrote a small package to illustrate the problem.
## R code
oldDir <- getwd()
setwd(tempdir())
url <- "http://nic.phys.ethz.ch/~chalabi/timeProb_0.001.tar.gz";
download.file(url, "timeProb_0.001.tar.gz")
install.packages("timeProb_0.001.tar.gz", repos = NULL)
# you also need to install another package which uses `time<-`.
# for example zoo
if(!require(zoo))
install.packages("zoo")
# Now we quit and start a new R session
setwd(oldDir)
q()
# new R
# we first load timeProb
library(timeProb)
# and then run the demo
demo(timeProb)
# now we quit and start again a new session
q()
# new R
# but now we first load zoo and after timeProb
library(zoo)
library(timeProb)
# and run again the demo
demo(timeProb)
## end R code
As far as I understand it, two packages can not coexist if one of
them defines an S3 generic and the other one defines an S4 generic
with the same name.
Or am I missing an option when defining the S4 generic?
JC>
JC> As a postscript, here is the current plan, not yet committed, pending
JC> some more testing:
JC> - the bad methods will be allowed
JC> - warnings when a class is defined with such methods for a superclass
JC> - probably some other warnings, but not for an ordinary call to the
JC> method (it's the MISSING calls to the method that are the disaster).
JC>
Thanks for giving more information concerning the current plan.
JC> More later,
JC> John
JC>
regards,
Yohan
--
PhD student
Swiss Federal Institute of Technology
Zurich
www.ethz.ch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R for Vistax64
Look in MkRules and the rw-FAQ. You can easily build R under Mingw64, but no one has reported making it run -- and several have reported failures. Commercail vendors have built 64-bit R under other Windwos compilers. On Wed, 11 Mar 2009, Sim, Fraser wrote: Hi all, I have successfully built from source the 32-bit version of R on my Vista 64-bit box. I was hoping to graduate to a 64-bit version so I could analyze some larger data sets. I have 8gb RAM installed. I downloaded the latest 64-bit versions of Perl and MinGW but wasn't sure how to edit the source code to have it build using the 64-bit versions. I did change my PATH variable to point to the bin directories of the 64-bit Perl and MinGW packages. Any pointers would be very helpful. Thanks, Fraser Fraser Sim, PhD Assistant Professor of Neurology & Neurosurgery University of Rochester [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] better function name: make or as
I've written a function (for the 'oce' package) that takes a list of one type of object (a "station", observations made by a ship at one location), and creates another object (a "section", containing a sequence of station observations). My question is, should I name my function "make.section()" or "as.section()"? I wouldd like to pattern the name on other R functions, but I'm having difficulty understanding when 'as' and 'make' are used. (At the moment, I am using 'make', because it seems to me that 'as' is mainly for mapping input to output on a sort of one-to-one basis.) Any suggestions? -- View this message in context: http://www.nabble.com/better-function-name%3A-make-or-as-tp22465595p22465595.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R for Vistax64
On Wed, Mar 11, 2009 at 1:15 PM, Sim, Fraser wrote: > Hi all, > > I have successfully built from source the 32-bit version of R on my > Vista 64-bit box. I was hoping to graduate to a 64-bit version so I > could analyze some larger data sets. I have 8gb RAM installed. We (REvolution Computing) are beta testing a 64-bit build of R (2.7.2) and its packages for Windows now. There's more information at: http://www.revolution-computing.com/products/windows-64bit.php # David Smith -- David M Smith Director of Community, REvolution Computing www.revolution-computing.com Tel: +1 (206) 577-4778 x3203 (Seattle, USA) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] help.search(): "Error in .readRDS(hs_file) : error reading from connection" (PR#13591)
Full_Name: Don Maszle
Version: R version 2.8.1 (2008-12-22)
OS: Linux hood.mendelbio.com 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008
x86_64 x86_64 x86_64 GNU/Linux
Submission from: (NULL) (206.86.87.3)
I have resolved the problem, but this is a possible regression to a problem
listed in the bug fixes for 2.3.1.
After a new installation, help.search() on any search string without a package
restriction issued:
"Error in .readRDS(hs_file) : error reading from connection"
With a package restriction, it would work fine. (See two probable but not
directly observed exceptions below.)
I installed 2.8.1 from an RPM from CRAN. While installing additional packages,
my installation crashed due to me underestimating the required disk space. An
apparent result of that was that one or two Meta/hsearch.rds files were not
created properly. The ones in R.cache and Depela existed, but were of zero
size. Once I re-installed those packages the problem went away.
>From the 2.3.1 comments, I assume this should not break the entire help.search
system, unless the R.cache index file is needed to cache other files!
Also, before reinstallation, I tried to run help.search('', package='R.cache',
rebuild=T) but it did not seem to have any effect.
~drm
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Could you please add "time<-" as a generic function in the 'stats' package ?
The problems are related to masking objects (in this case `time<-` ) in
the search list, not especially related to methods.
It was in order to get around such problems that NAMESPACE was added to
R. You should use it, but it applies to evaluating calls to functions
in the package, by avoiding the dependency on the order of packages in
the search list. To ensure correct results, you need to call a
function from your package (i.e., one that is not masked). The
computations in the function will see what has been imported into the
namespace.
For example, if you do the following:
1. add a NAMESPACE file, for example containing:
import(stats)
import(zoo)
exportPattern("^[a-zA-Z]")
2. Do the computations in a function in your package, say doDemo(),
with a few show(time()) lines added to print things.
3. With the import(zoo), no need to define `time<-` as an S3 generic.
Then things behave with or without zoo attached, because the
computations are defined by your namespace. Without attaching zoo:
---
> require(timeProb)
Loading required package: timeProb
> doDemo()
[1] "aTest2"
Loading required package: zoo
Attaching package: 'zoo'
The following object(s) are masked from package:timeProb :
time<-
The following object(s) are masked from package:base :
as.Date.numeric
[1] "aTest3"
[1] "2003-02-01" "2003-02-03" "2003-02-07" "2003-02-09" "2003-02-14"
--
Notice the masking of `time<-`. Did you notice that before?
Yohan Chalabi wrote:
> "JC" == John Chambers
> on Wed, 11 Mar 2009 09:57:43 -0700
>
>
>JC> Whatever one wants for an S3 generic, it's not needed to do what,
>JC> presumably, you want here.
>JC>
>JC> And for sure it is no excuse for S3 methods for S4 classes.
>JC>
>JC> Back to basics: To write S4 methods for an existing function, the clean
>JC> and simple way is usually:
>JC>
>JC> setGeneric("time<-")
>JC>
>JC> If your package depends on one that has S3 methods for this function,
>JC> there will be a version of the function imported into your namespace.
>JC> That function will then be the default method.
>JC>
>JC> Presumably you want to ensure that S3 methods, for S3 classes, are
> still
>JC> dispatched. Quite reasonable and it should follow from the call to
>JC> setGeneric.
>JC>
>JC> If you wanted to have your own S3 methods or if you weren't willing to
>JC> assume an S3 generic imported, you could do a 2-line version:
>JC>
>JC> R(r48103)> `time<-` <- function(x, value) UseMethod("time<-")
>JC> R(r48103)> setGeneric("time<-")
>JC> [1] "time<-"
>JC> R(r48103)> showMethods("time<-", include = TRUE)
>JC> Function: time<- (package .GlobalEnv)
>JC> x="ANY"
>JC> function (x, value)
>JC> UseMethod("time<-")
>
> In my opinion you example only works in '.GlobalEnv' environement, but
> does not work when implemented in a package.
>
> I wrote a small package to illustrate the problem.
>
> ## R code
> oldDir <- getwd()
> setwd(tempdir())
>
> url <- "http://nic.phys.ethz.ch/~chalabi/timeProb_0.001.tar.gz";
> download.file(url, "timeProb_0.001.tar.gz")
> install.packages("timeProb_0.001.tar.gz", repos = NULL)
>
> # you also need to install another package which uses `time<-`.
> # for example zoo
> if(!require(zoo))
> install.packages("zoo")
>
> # Now we quit and start a new R session
> setwd(oldDir)
> q()
>
> # new R
>
> # we first load timeProb
> library(timeProb)
>
> # and then run the demo
> demo(timeProb)
>
> # now we quit and start again a new session
> q()
>
> # new R
>
> # but now we first load zoo and after timeProb
> library(zoo)
> library(timeProb)
>
> # and run again the demo
> demo(timeProb)
>
> ## end R code
>
> As far as I understand it, two packages can not coexist if one of
> them defines an S3 generic and the other one defines an S4 generic
> with the same name.
>
> Or am I missing an option when defining the S4 generic?
>
>JC>
>JC> As a postscript, here is the current plan, not yet committed, pending
>JC> some more testing:
>JC> - the bad methods will be allowed
>JC> - warnings when a class is defined with such methods for a superclass
>JC> - probably some other warnings, but not for an ordinary call to the
>JC> method (it's the MISSING calls to the method that are the disaster).
>JC>
>
> Thanks for giving more information concerning the current plan.
>
>JC> More later,
>JC> John
>JC>
>
>
> regards,
> Yohan
>
> --
> PhD student
> Swiss Federal Institute of Technology
> Zurich
>
> www.ethz.ch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
