Re: [Rd] RFC: rawConnection (was "loop connections")
[EMAIL PROTECTED] wrote: > Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > >>I think the cost of duplicating as.raw is worse than the cost of using >>extra memory. If the lack of symmetry bothers you, a solution is to >>require a raw object as input. > > > It wouldn't exactly be duplicating as.raw since this way of converting > to raw is actually to do nothing at all, just to treat the object as > if it is already raw. But, I don't have a strong opinion. I haven't looked at as.raw, but I think it does something other than that. For example, rawToChar(as.raw(1:10)) gives "\001\002\003\004\005\006\a\b\t\n" I don't know if there's a way to do exactly what you're proposing. One argument against it is that the bytes for an object may vary from platform to platform (big versus little endian, maybe 32 vs 64 bit), whereas we try to make R code platform independent when we can. >> > Currently, textConnection() makes a copy for "r" connections >> >>>but writes directly to an R object for "w" connections. The "w" case >>>is buggy; you can crash R by removing the target object while the >>>connection is being used. I'm not familiar enough with R internals to >>>know how to fix that. Maybe the object has to be searched for every >>>time the connection is used, to avoid potentially stale pointers? > > >>I've been having an argument with some other people about something >>related to this. I think they would say that the language doesn't >>support writing to a variable. > > > I tried changing textConnection output connections to look up the > destination object on every access and that seems to solve the problem > without being terribly expensive. > > >>If so, then a binary mode rawConnection (with mention of the way to >>convert in the Rd file) would be good enough for me. > > > It seems we are coming back to something close to what I had > originally implemented? Probably! The differences I still know about are: - I'd like the name to reflect the data source, so rawConnection or something similar rather than overloading textConnection. - It needs a man page, or to be included on the textConnection man page. Duncan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Build R with ATLAS
Hi, I followed this message, https://stat.ethz.ch/pipermail/r-devel/2004-February/028942.html, to compile ATLAS with gcc and g77 on AMD Opteron. I then followed the instructions on this message, https://stat.ethz.ch/pipermail/r-devel/2004-February/028966.html, to convert static libraries to dynamic libraries. However, when I tried to configure R-devel, I got the following error messages in config.log: configure:33172: checking for sgemm_ in -lf77blas configure:33210: /usr/pgi/linux86-64/6.0/bin/pgcc -o conftest -g -O2 -mieee-fp -I/usr/pgi/linux86-64/6.0/include -I/usr/pgi/l\ inux86-64/6.0/include/CC -L/usr/pgi/linux86-64/6.0/libso -L/usr/lib64 -L/usr/local/lib64 conftest.c -lf77blas -latlas -lpgftn\ rtl -lnspgc -lpgc -lm -ldl -lm >&5 pgcc-Warning-Unknown switch: -mieee-fp NOTE: your evaluation license will expire in 14 days, 0.426 hours. For a permanent license, please read the order acknowledgement that you received. Connect to https://www.pgroup.com/License with the username and password in the order acknowledgement. Name: lai User: lai Email: [EMAIL PROTECTED] Hostid: PGI=1AE0190CAB621CB217 /usr/local/lib64/libf77blas.so: undefined reference to `e_wsfe' /usr/local/lib64/libf77blas.so: undefined reference to `do_fio' /usr/local/lib64/libf77blas.so: undefined reference to `s_stop' /usr/local/lib64/libf77blas.so: undefined reference to `s_wsfe' My LD_LIBRARY_PATH=/usr/pgi/linux86-64/libso:/usr/local/lib64 Can anyone advise me on how to build R with ATLAS? Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] lattice and for loop
- Forwarded message from Sandy Weisberg <[EMAIL PROTECTED]> -
OK, here is my R bug:
library(lattice)
x <- rnorm(20)
y <- rnorm(20)
z <-rep(c(1,2),10)
xyplot(y~x|z)
# the above works fine. Now try this:
for (j in 1:1) {xyplot(y~x|z)}
# no graph is produced.
--
Sanford Weisberg
University of Minnesota, School of Statistics
312 Ford Hall, Minneapolis, MN 55455
612-625-8355, FAX 612-624-8868
St. Paul office: 146 Classroom-Office Building, 612-625-8777
[EMAIL PROTECTED]
- End forwarded message -
Sandy originally found this in
R 2.1.1 (for Windows).
I have tried this in
R 2.1.1 Patched (2005-08-04).
R 2.1.1 Patched (2005-09-02).
R 2.2.0 Under development (unstable) (2005-09-01).
all on
Linux 2.6.11.4-21.7-smp i686 athlon i386 GNU/Linux
Suse 9.3
gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
So our question is: is this a bug or a feature?
--
Charles Geyer
Professor, School of Statistics
University of Minnesota
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] lattice and for loop
See
http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-do-lattice_002ftrellis-graphics-not-work_003f
-roger
Charles Geyer wrote:
> - Forwarded message from Sandy Weisberg <[EMAIL PROTECTED]> -
>
> OK, here is my R bug:
>
> library(lattice)
> x <- rnorm(20)
> y <- rnorm(20)
> z <-rep(c(1,2),10)
> xyplot(y~x|z)
> # the above works fine. Now try this:
>
> for (j in 1:1) {xyplot(y~x|z)}
>
> # no graph is produced.
>
--
Roger D. Peng
http://www.biostat.jhsph.edu/~rpeng/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
I appreciate the update. We will consider using Linux, which leads me to one more question: what is the maximum RAM that R can use on each platform (Linux and Windows)? Thanks again for your prompt responses. M. -Original Message- From: Luke Tierney [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 31, 2005 6:04 PM To: Duncan Murdoch Cc: Milton Lopez; r-devel@r-project.org Subject: Re: [Rd] 64 bit R for Windows On Wed, 31 Aug 2005, Duncan Murdoch wrote: > I would say it will be at least a year, and most likely longer. The > tools used to build R haven't been ported to 64 bit Windows yet. After > those are done (by the MinGW project, not us), we'll need someone with a > 64 bit Windows machine to handle builds there. > > Duncan Murdoch An additional factor is that MinGW will almost certainly follow the MS idea that long's are 4 bytes even under Win64, unlike what every other 64-bit OS does. It will take a fair bit of time and someonw with the motivation to do so to sort out the consequences (which may not be very great but even establishing that may be non-trivial). luke __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check warning message "print.check_code_usage_in_package"
We're seeing many warnings like this: Warning: S3 method 'print.check_code_usage_in_package' was declared in NAMESPACE but not found But the package's NAMESPACE does not contain such a declaration. Seeing this in many Bioconductor packages when running R CMD check on Windows with R-devel built 1 Sept. Below is a snip of the output from R CMD check. Any ideas of what this message is really trying to tell me? Thanks, + seth * checking S3 generic/method consistency ... WARNING Warning: S3 method 'print.check_code_usage_in_package' was declared in NAMESPACE but not found See section 'Generic functions and methods' of the 'Writing R Extensions' manual. * checking replacement functions ... WARNING Warning: S3 method 'print.check_code_usage_in_package' was declared in NAMESPACE but not found In R, the argument of a replacement function which corresponds to the right hand side must be named 'value'. * checking foreign function calls ... WARNING Warning: S3 method 'print.check_code_usage_in_package' was declared in NAMESPACE but not found See section 'System and foreign language interfaces' of the 'Writing R Extensions' manual. * checking Rd files ... WARNING Warning: S3 method 'print.check_code_usage_in_package' was declared in NAMESPACE but not found See chapter 'Writing R documentation files' in manual 'Writing R Extensions'. * checking for missing documentation entries ... WARNING Warning: S3 method 'print.check_code_usage_in_package' was declared in NAMESPACE but not found All user-level objects in a package should have documentation entries. See chapter 'Writing R documentation files' in manual 'Writing R Extensions'. * checking for code/documentation mismatches ... WARNING Warning: S3 method 'print.check_code_usage_in_package' was declared in NAMESPACE but not found Warning: S3 method 'print.check_code_usage_in_package' was declared in NAMESPACE but not found __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
On 9/2/2005 11:59 AM, Milton Lopez wrote: > I appreciate the update. We will consider using Linux, which leads me to > one more question: what is the maximum RAM that R can use on each > platform (Linux and Windows)? On 32 bit Windows, I believe the limit is normally 2 G total for all user processes, but can be raised to 3 G with some work. (If you have a 4 G machine, the OS reserves 1 or 2 G for itself.) R can use as much memory as Windows will give it, but may not be able to make large allocations if memory is fragmented, or reserved by other processes. The limit under 64 bit Linux is much larger, but I don't know exactly what. Duncan Murdoch > > Thanks again for your prompt responses. > > > M. > > -Original Message- > From: Luke Tierney [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 31, 2005 6:04 PM > To: Duncan Murdoch > Cc: Milton Lopez; r-devel@r-project.org > Subject: Re: [Rd] 64 bit R for Windows > > On Wed, 31 Aug 2005, Duncan Murdoch wrote: > >> I would say it will be at least a year, and most likely longer. The >> tools used to build R haven't been ported to 64 bit Windows yet. > After >> those are done (by the MinGW project, not us), we'll need someone with > a >> 64 bit Windows machine to handle builds there. >> >> Duncan Murdoch > > An additional factor is that MinGW will almost certainly follow the MS > idea that long's are 4 bytes even under Win64, unlike what every other > 64-bit OS does. It will take a fair bit of time and someonw with the > motivation to do so to sort out the consequences (which may not be > very great but even establishing that may be non-trivial). > > luke > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
"Milton Lopez" <[EMAIL PROTECTED]> writes: > I appreciate the update. We will consider using Linux, which leads me to > one more question: what is the maximum RAM that R can use on each > platform (Linux and Windows)? > > Thanks again for your prompt responses. On Win32, something like 3GB. Maybe a little more on Linux32, but there's a physical limit at 4GB. On Linux 64, the motherboards set the limit in practice, 32GB systems have been reported working and I think at least 64GB should be possible. I seem to recall that the maximum _virtual_ memory is not quite 2^64, but it will be pretty huge (2^48, 256TB)?. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning message "print.check_code_usage_in_package"
> Seth Falcon writes: > We're seeing many warnings like this: > Warning: S3 method 'print.check_code_usage_in_package' was declared in > NAMESPACE but not found > But the package's NAMESPACE does not contain such a declaration. > Seeing this in many Bioconductor packages when running R CMD check on > Windows with R-devel built 1 Sept. My SVN checkout of the r-devel sources seems to have it: $ grep print.check_code_usage_in_package * QC.R:print.check_code_usage_in_package <- and it also seems to be in the r-devel .tar.gz from ETHZ. Are you sure you have a current version of r-devel's tools/R/QC.R? Best -k > Below is a snip of the output from R CMD check. Any ideas of what > this message is really trying to tell me? > Thanks, > + seth > * checking S3 generic/method consistency ... WARNING > Warning: S3 method 'print.check_code_usage_in_package' was declared in > NAMESPACE but not found > See section 'Generic functions and methods' of the 'Writing R Extensions' > manual. > * checking replacement functions ... WARNING > Warning: S3 method 'print.check_code_usage_in_package' was declared in > NAMESPACE but not found > In R, the argument of a replacement function which corresponds to the right > hand side must be named 'value'. > * checking foreign function calls ... WARNING > Warning: S3 method 'print.check_code_usage_in_package' was declared in > NAMESPACE but not found > See section 'System and foreign language interfaces' of the 'Writing R > Extensions' manual. > * checking Rd files ... WARNING > Warning: S3 method 'print.check_code_usage_in_package' was declared in > NAMESPACE but not found > See chapter 'Writing R documentation files' in manual 'Writing R > Extensions'. > * checking for missing documentation entries ... WARNING > Warning: S3 method 'print.check_code_usage_in_package' was declared in > NAMESPACE but not found > All user-level objects in a package should have documentation entries. > See chapter 'Writing R documentation files' in manual 'Writing R > Extensions'. > * checking for code/documentation mismatches ... WARNING > Warning: S3 method 'print.check_code_usage_in_package' was declared in > NAMESPACE but not found > Warning: S3 method 'print.check_code_usage_in_package' was declared in > NAMESPACE but not found > __ > 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] 64 bit R for Windows
> "PD" == Peter Dalgaard <[EMAIL PROTECTED]> > on 02 Sep 2005 18:48:24 +0200 writes: PD> "Milton Lopez" <[EMAIL PROTECTED]> writes: >> I appreciate the update. We will consider using Linux, >> which leads me to one more question: what is the maximum >> RAM that R can use on each platform (Linux and Windows)? >> >> Thanks again for your prompt responses. PD> On Win32, something like 3GB. Maybe a little more on PD> Linux32, but there's a physical limit at 4GB. for a *single* object, yes. However (and Peter knows this probably better than me ..), R's workspace can be very much larger which makes it realistically possible to start *using* R functions on objects of around 4GB. Someone (Venables & Ripley ?) have once stated the rule of thumb that you need about 5--10 times the size of your "single" large object for your "workspace", because of (intermediate) copies, sometimes multiple ones are needed, or at least part of the current implementations of many basic algorithms / functions. In other words, if you got a 32 GB RAM, you could probably start to work with objects of the size of (a little less than) 4GB relatively comfortably. Martin Maechler PD> On Linux 64, the motherboards set the limit in practice, PD> 32GB systems have been reported working and I think at PD> least 64GB should be possible. I seem to recall that the PD> maximum _virtual_ memory is not quite 2^64, but it will PD> be pretty huge (2^48, 256TB)?. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
On Fri, 2 Sep 2005, Martin Maechler wrote: >> "PD" == Peter Dalgaard <[EMAIL PROTECTED]> >> on 02 Sep 2005 18:48:24 +0200 writes: > >PD> "Milton Lopez" <[EMAIL PROTECTED]> writes: > >>> I appreciate the update. We will consider using Linux, >>> which leads me to one more question: what is the maximum >>> RAM that R can use on each platform (Linux and Windows)? >>> >>> Thanks again for your prompt responses. > >PD> On Win32, something like 3GB. Maybe a little more on >PD> Linux32, but there's a physical limit at 4GB. > > for a *single* object, yes. However (and Peter knows this > probably better than me ..), R's workspace can be very much > larger which makes it realistically possible to start *using* R > functions on objects of around 4GB. No, no. On *Windows* there is an address space limit of about 3Gb (and on other 32bit systems) On a 64bit system the limit is that a vector can't have length greater than 2^31, but this would be 8Gb for integers or 16Gb for doubles and so represents larger objects than you would want to handle on most current 64-bit systems. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 64 bit R for Windows
Martin Maechler <[EMAIL PROTECTED]> writes: > > "PD" == Peter Dalgaard <[EMAIL PROTECTED]> > > on 02 Sep 2005 18:48:24 +0200 writes: > > PD> "Milton Lopez" <[EMAIL PROTECTED]> writes: > > >> I appreciate the update. We will consider using Linux, > >> which leads me to one more question: what is the maximum > >> RAM that R can use on each platform (Linux and Windows)? > >> > >> Thanks again for your prompt responses. > > PD> On Win32, something like 3GB. Maybe a little more on > PD> Linux32, but there's a physical limit at 4GB. > > for a *single* object, yes. However (and Peter knows this > probably better than me ..), R's workspace can be very much > larger which makes it realistically possible to start *using* R > functions on objects of around 4GB. Notice that I said "Linux32" there The single-object size limit is of course relevant on 64 bit systems, so thanks for the reminder. > PD> On Linux 64, the motherboards set the limit in practice, > PD> 32GB systems have been reported working and I think at > PD> least 64GB should be possible. I seem to recall that the > PD> maximum _virtual_ memory is not quite 2^64, but it will > PD> be pretty huge (2^48, 256TB)?. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check and interfacing packages
For an R package whose purpose is to interface to other software, since such other software is not necessarily being on CRAN how does one proceed so that the R package can pass 'R CMD check'? None of the examples or demos in the package can run without the software being interfaced to. Is there an example of such a package that could be used as a prototype? Thanks. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check warning message "print.check_code_usage_in_package"
On 2 Sep 2005, [EMAIL PROTECTED] wrote: > My SVN checkout of the r-devel sources seems to have it: > > $ grep print.check_code_usage_in_package * > QC.R:print.check_code_usage_in_package <- > > and it also seems to be in the r-devel .tar.gz from ETHZ. > > Are you sure you have a current version of r-devel's tools/R/QC.R? You were right, an svn update and rebuild seems to have resolved things. I guess I must have caught a bad revision. Still seems like a very odd message since it was refering to the tools package and not the package being checked. Thanks for the hint. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
