Re: [Rd] Suggestion for serialization performance improvement on Windows
On Fri, 9 Jul 2010, Bryan W. Lewis wrote: Dear R developers, The slow performance of serializing to a raw vector on Windows is an issue that has appeared in this list before. It appears to be due to References? the frequent use of realloc from the resize_buffer method in serialize.c. I suggest a more granular, but still incremental, re-allocation of memory. For example change near the top of resize_buffer to: R_size_t newsize = needed + 65536 - (needed % 65536); or some other similar small multiple of a typical system page size. for some definition of 'small multiple' I have found this to dramatically improve performance of serialization to raw vectors on Windows. However, I didn't and you presented no evidence. On HB's 2008 example your idea achieved for me a speedup of about 3x. A much better speedup (15x) was achieved by switching serialize.c to use the alternative malloc used by memory.c, and using a much larger page size (e.g. 1Mb) was better still. But changing the re-allocation strategy resulted in a 150x speed up, to levels comparable to decent operating systems like Linux and Solaris with the existing code. (In case it matters, I was using x64 Windows 7.) Ideally you would have - given references for your claims - given examples for why this was too slow for you - specified an exact patch with performance comparisons for your examples - given your credentials (see the comment about 'good manners' in the R posting guide). It is very likely that we would not have been able to use any patch you supplied without such credentials. So please test R-devel, and if there is still a problem reply with all the details omitted here. -- 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] Non-blocking Eval
Sorry I phrased that badly. What I'm trying to do is asynchronously add data to R, i.e. a program will periodically dump some readings to the Rserver and then later on another program will run some analysis scripts on them. I have managed to add the data via CMD_detachedVoidEval as you suggested. How exactly do I go about attaching to the session again? I know it involves some form of session key that comes back from the detach call, but what from does it take? And how do I use this? Thanks AgainMartin Subject: Re: [Rd] Non-blocking Eval From: simon.urba...@r-project.org Date: Mon, 19 Jul 2010 11:34:29 -0400 CC: r-devel@r-project.org To: mk2...@hotmail.com On Jul 19, 2010, at 10:58 AM, Martin Kerr wrote: Hello, I'm currently working with the C++ version of the Rserve Client as part of a student project. Is there an implementation of a non-blocking interface to Rserve in C++? I can find one via the Java JRI but no equivalent in C++. (Please note that stats-rosuda-devel is the correct list for this.) I'm not quite sure what you mean, because in JRI there is idleEval() which is non-blocking in the sense that it doesn't do anything if R is busy but that doesn't apply to Rserve as by definition R cannot be busy there. There is no non-blocking interface to JRI - all calls are synchronous. If your question is whether you can start an evaluation in Rserve and not wait for the result then there is CMD_detachedVoidEval in Rserve, but the C++ client only implements a subset of the API which does not include that -- however, it is trivial to implement (just send a request with CMD_detachedVoidEval as there is nothing to decode). Cheers, Simon _ Do you have a story that started on Hotmail? Tell us now [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Package ff building error on solaris x64 10u7
Hi again, I am trying to building ff on solaris x64 10u7, and failed with the following result: -bash-3.00$ R CMD INSTALL ff * installing to library '/opt/R/R2-11-1/lib/R/library' * installing *source* package 'ff' ... checking for gcc... /opt/sunstudio12.1/bin/cc -m64 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /opt/sunstudio12.1/bin/cc -m64 accepts -g... yes checking for /opt/sunstudio12.1/bin/cc -m64 option to accept ISO C89... none needed checking how to run the C preprocessor... /opt/sunstudio12.1/bin/cc -m64 -E checking for grep that handles long lines and -e... /usr/sfw/bin/ggrep checking for egrep... /usr/sfw/bin/ggrep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/vfs.h usability... yes checking sys/vfs.h presence... yes checking for sys/vfs.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking for sys/stat.h... (cached) yes checking for unistd.h... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/mount.h usability... yes checking sys/mount.h presence... yes checking for sys/mount.h... yes checking for struct statfs.f_iosize... no checking sys/statfs.h usability... yes checking sys/statfs.h presence... yes checking for sys/statfs.h... yes checking for struct statfs.f_iosize... (cached) no checking sys/statvfs.h usability... yes checking sys/statvfs.h presence... yes checking for sys/statvfs.h... yes checking for off_t... yes checking for size_t... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for _LARGEFILE_SOURCE value needed for large files... no checking for fseeko... yes configure: creating ./config.status config.status: creating src/ac_config.h ** libs /opt/sunstudio12.1/bin/CC -m64 -lCrun -I/opt/R/R2-11-1/lib/R/include -I/opt/R/R2-11-1/include -I/usr/sfw/include -I/opt/sfw/include -I/usr/openwin/share/include-KPIC -xO3 -c Error.cpp -o Error.o /opt/sunstudio12.1/bin/CC -m64 -lCrun -I/opt/R/R2-11-1/lib/R/include -I/opt/R/R2-11-1/include -I/usr/sfw/include -I/opt/sfw/include -I/usr/openwin/share/include-KPIC -xO3 -c FSInfo_statfs.cpp -o FSInfo_statfs.o FSInfo_statfs.cpp, line 50: Error: Could not find a match for statfs(const char*, statfs*) needed in ff::getFSInfo(const char*, ff::FSInfo). FSInfo_statfs.cpp, line 52: Error: f_bavail is not a member of statfs. FSInfo_statfs.cpp, line 53: Warning: The variable sfs has not yet been assigned a value. 2 Error(s) and 1 Warning(s) detected. *** Error code 2 make: Fatal error: Command failed for target `FSInfo_statfs.o' ERROR: compilation failed for package 'ff' * removing '/opt/R/R2-11-1/lib/R/library/ff' -bash-3.00$ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building rattle on Solaris 10u7 X86
Hi Professor Brian Ripley, Thanks for your help, Our experience is - the X11 installation on Solaris is too old for these packages. We use the one from OpenCSW (see the R-admin manual). cairographics in particular has moved on a lot since the 2005 release of Solaris 10 (cairo reached version 1.0 after that). Do you suggest to use the new X11 from OpenCSW to replace the one shipped with Solaris, and do you have any procedural guides. - we failed to build RGtk2 with the SunStudio compiler, and had to use gcc. I used SunStudio building R, do we need to use the same compiler for both R and Packages? I followed the guides in https://www.initworks.com/wiki/pages/viewpage.action?pageId=6521038 to build R with SunStudio, is there some similar guides when using gcc? Note that nothing in this message is about 'building rattle' (your subject line): it is about installing packages rattle's GUI depends on. Let me warn you that rattle doesn't just depend on RGtk2, it depends on RGtk2 built with libglade2 support: which is optional and not installed by default on Solaris (and often not elsewhere). Yes, I am trying to install the packages which are dependent by Rattle, and RGtk2 is the first one. Note that in R terminolgy (see Writing R Extensions), building a package (R CMD build) is not the same thing as installing one (R CMD INSTALL). Actually I am new to R, and don't really know the differences between building and installing packages. The R CMD INSTALL command just can install packages from source code. Xiaobo Gu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Telling R CMD check where to find libraries
Hello everybody, Currently I'm developing a library, which uses some functions from another package (namely plotrix). Consequently, I listed this dependency in the DESCRIPTION file. When I try to run R CMD check mypackage, the check fails, for the library plotrix cannot be found on the system. As far as I understood R CMD check uses --vanilla implicitly, thus, no startup files are read. Hence, plotrix cannot be found by R CMD check, since it is only installed locally (I've no admin privileges on this machine) and the path to the library is given in .Rprofile, which in turn is not read by R CMD check. If I provide the flag -l /path/to/site/libs, it works as expected but with the side effect that the test installation is carried out in this directory as well, which I do not like either (this directory should contain only stable packages and not packages which are still under construction). So which possibilities do I have? BR Thorn __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] garbage collection memory leaks in 'R', it seems...
Peter, OK, thanks for the info! My work-around for the foreseeable future is to simply launch 'R' from a command line with the --no-save --no-restore options, then break the program up a bit. Regards, Mike Telescopes and bathyscaphes and sonar probes of Scottish lakes, Tacoma Narrows bridge collapse explained with abstract phase-space maps, Some x-ray slides, a music score, Minard's Napoleanic war: The most exciting frontier is charting what's already here. -- xkcd -- Help protect Wikipedia. Donate now: http://wikimediafoundation.org/wiki/Support_Wikipedia/en On Sat, Jul 17, 2010 at 2:11 AM, Peter Dalgaard pda...@gmail.com wrote: Mike Williamson wrote: Hello developers, I noticed that if I am running 'R', type rm(list=objects()) and gc(), 'R' will still be consuming (a lot) more memory than when I then close 'R' and re-open it. In my ignorance, I'm presuming this is something in 'R' where it doesn't really do a great job of garbage collection... at least not nearly as well as Windows or unix can do garbage collection. Am I right? If so, is there any better way to clean up the memory that 'R' is using? I have a script that runs a fairly large job, and I cannot keep it going on its own in a convenient way because of these remnants of garbage that pile up and eventually leave so little memory remaining that the script crashes. In a word, no, R is not particularly bad at GC. The internal gc() does a rather good job of finding unused objects as you can see from its returned report. Whether that memory is returned to the OS is a matter of the C-level services (malloc/free) that R's allocation routines use. As far as I recall, Windows free() just never returns memory to the OS. In general, whether it can be done at all depends on which part of the heap you have freed since you have to free from the end of it. (I.e., having a tiny object sitting at the end of the heap will force the entire range to be kept in memory.) R itself will allocate from freed-up areas of the heap as long as it can find a space that is big enough. However, there is always a tendency for memory to fragmentize so that you eventually have a pattern of many small objects with not-quite-big-enough holes between them. These issues affect most languages that do significant amounts of object allocation and destruction. You should not really compare it to OS level memory management because that's a different kettle of fish. In particular, user programs like R relies on having all objects mapped to a single linear address space, whereas the OS just needs to create a set of per-process virtual address spaces and has hardware help to do so. -- Peter Dalgaard Center for Statistics, Copenhagen Business School Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-blocking Eval
Martin, On Jul 20, 2010, at 8:10 AM, Martin Kerr wrote: Sorry I phrased that badly. What I'm trying to do is asynchronously add data to R, i.e. a program will periodically dump some readings to the Rserver and then later on another program will run some analysis scripts on them. That is an entirely different concept - the Rserve control commands (CMD_ctrlEval and CMD_ctrlSource) allow you to do that: evaluate code in the master server process. All subsequent clients are then working on the updated data. However, there is no support for control commands in the C++ client so following the same directions you'd have to add it (this time there is truly no data in the response as it is asynchronous so sending the request is sufficient). I have managed to add the data via CMD_detachedVoidEval as you suggested. How exactly do I go about attaching to the session again? I know it involves some form of session key that comes back from the detach call, but what from does it take? And how do I use this? The detach command will return a 32-byte session key which you use with the attach command. It is opaque to the application. However, this is a whole different story - the assumption was that you only need asynchronous evaluation so you would actually quit R in the client once detached. The session support (detach/attach) is for a different use - if you start a long computation but don't want to wait for the result and only come back later to collect the result. Cheers, Simon PS: please continue the discussion on stat-rosuda-devel as that is the correct place. Thanks AgainMartin Subject: Re: [Rd] Non-blocking Eval From: simon.urba...@r-project.org Date: Mon, 19 Jul 2010 11:34:29 -0400 CC: r-devel@r-project.org To: mk2...@hotmail.com On Jul 19, 2010, at 10:58 AM, Martin Kerr wrote: Hello, I'm currently working with the C++ version of the Rserve Client as part of a student project. Is there an implementation of a non-blocking interface to Rserve in C++? I can find one via the Java JRI but no equivalent in C++. (Please note that stats-rosuda-devel is the correct list for this.) I'm not quite sure what you mean, because in JRI there is idleEval() which is non-blocking in the sense that it doesn't do anything if R is busy but that doesn't apply to Rserve as by definition R cannot be busy there. There is no non-blocking interface to JRI - all calls are synchronous. If your question is whether you can start an evaluation in Rserve and not wait for the result then there is CMD_detachedVoidEval in Rserve, but the C++ client only implements a subset of the API which does not include that -- however, it is trivial to implement (just send a request with CMD_detachedVoidEval as there is nothing to decode). Cheers, Simon _ Do you have a story that started on Hotmail? Tell us now [[alternative HTML version deleted]] __ 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
[Rd] Extract callNextMethod array calls matrix?
I have a class that extends array and my method for [ stops with an error: setClass(A, contains=array) [1] A setMethod([, A, function(x, i, j, ..., drop = TRUE) new(A, callNextMethod())) [1] [ a-new(A,array(1:12,c(4,3,1))) a An object of class A , , 1 [,1] [,2] [,3] [1,]159 [2,]26 10 [3,]37 11 [4,]48 12 a[1:2,2:3,1] Error in x[i = i, j = j, NULL, ...] : incorrect number of dimensions Error in callNextMethod() : error in evaluating a 'primitive' next method A similar error does not occur when extending a matrix: setClass(M, contains=matrix) [1] M setMethod([, M, function(x, i, j, ..., drop = TRUE) new(M, callNextMethod())) [1] [ a-new(M,matrix(1:12,4,3)) a[1:2,2:3] An object of class M [,1] [,2] [1,]59 [2,]6 10 Is there a problem with my method definition for the array-extending class? My work-around is as follows: setMethod([, A, function(x, i, j, ..., drop = TRUE) new(A, `[`(as(x,array), i=i, j=j, ..., drop=drop))) [1] [ a[1:2,2:3,1] An object of class A [,1] [,2] [1,]59 [2,]6 10 Cheers, Dan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] new bug in install.packages()
Hi, install.packages() seems to be broken in latest R-devel snapshot (2010-07-19 r52561) if you are using an R/R.version$platform-library/x.y directory. .libPaths() [1] /home/hpages/R/x86_64-unknown-linux-gnu-library/2.12 [2] /home/hpages/R-2.12/library install.packages(car) Error in sprintf(gettext(fmt, domain = domain), ...) : too few arguments Looks like the problem is in these lines (lines 194-197 in file src/library/utils/R/packages2.R): lib - .libPaths()[1L] if (length(.libPaths()) 1L) message(gettextf(Installing package(s) into %s\n(as %s is unspecified), sQuote(lib)), domain = NA) Cheers, H. sessionInfo() R version 2.12.0 Under development (unstable) (2010-07-19 r52561) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8 [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8 [7] LC_PAPER=en_US.utf8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.12.0 -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] broken link to new features in R-devel: no NEWS file
Hi The link from CRAN to new features in R-devel hasn't been working for a few days. Specifically, there is no NEWS file in https://svn.r-project.org/R/trunk/, though there is an ONEWS. The link is in the Source code for all platforms subwindow, where it says: Daily snapshots of current patched and development versions are available here. Please read about new features and bug fixes before filing corresponding feature requests or bug reports. Mark -- Mark Bravington CSIRO Mathematical Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package RPostgreSQL_0.1-6.tar.gz has been checked and built
Hi Dirk I think there are problems with pg_config, the configure script of RPostgreSQL checks for pg_config and got ¡°checking for pg_config... /usr/bin/pg_config¡±. In Solaris 10u7 X64, three versions of PostgreSQL are installed, there are in /usr/postgres/8.2(8.2.9) and /usr/postgres/8.3(8.3.3), the corresponding bin files are in /usr/postgres/version/bin and /usr/postgres/version/bin/amd64, and the libraries in /usr/bin is 8.1.11 and it seems a 32bit one, and I can¡¯t find the 64bit version bins for 8.1.11. I'll try uninstall 8.1.11 and install 8.2.9, and my question is how to let RPostgreSQL configure script find the 64bit pg_config. Xiaobo Gu On Tue, Jul 20, 2010 at 10:32 PM, ¹ËС²¨ guxiaobo1...@gmail.com wrote: Hi Dirk, I think this discussion should help : http://stackoverflow.com/questions/1836333/how-can-i-compile-64-bit-postgres-bindings-for-perl-on-solaris, are there environment variables I can set to point to 64bit libraries, or I can set the 64bit libraries path /usr/local/psql/lib before /usr/lib, I'll let you know the results tomorrow. Xiaobo.Gu -Original Message- From: Dirk Eddelbuettel [mailto:e...@debian.org] Sent: Tuesday, July 20, 2010 7:11 PM To: Amber Cc: Dirk Eddelbuettel; Uwe Ligges Subject: Re: Package RPostgreSQL_0.1-6.tar.gz has been checked and built Hi Amber, I'm at the useR conference with imperfect connectivity adn can't help much. I also noticed that Solaris often comes up with particular errors -- see Prof Ripley's response to your Rattle query. RPostgresql may be easy to get built, but you may have to adapt configure.in. On 20 July 2010 at 14:08, Amber wrote: | Hi Dirk, | There are problems building RPostgreSQL on 64bit solaris, | The server has preinstalled PostgreSQL 8.1 client and server binaries , and | we also installed Greenplum SNE 3.3.5.0 server and client installed, but the | postgres user, which I used to build R and RPostgreSQL can't see Greenplum | binaries, the error messages are: | | -bash-3.00$ R CMD INSTALL RPostgreSQL | * installing to library '/opt/R/R2-11-1/lib/R/library' | * installing *source* package 'RPostgreSQL' ... | checking for gcc... /opt/sunstudio12.1/bin/cc -m64 | checking for C compiler default output file name... a.out | checking whether the C compiler works... yes | checking whether we are cross compiling... no | checking for suffix of executables... | checking for suffix of object files... o | checking whether we are using the GNU C compiler... no | checking whether /opt/sunstudio12.1/bin/cc -m64 accepts -g... yes | checking for /opt/sunstudio12.1/bin/cc -m64 option to accept ISO C89... none | needed | checking for pg_config... /usr/bin/pg_config | checking for /usr/include/pgsql/libpq-fe.h... yes Good! | configure: creating ./config.status | config.status: creating src/Makevars | ** libs | /opt/sunstudio12.1/bin/cc -m64 -xc99=all -G -L/opt/R/R2-11-1/lib | -L/usr/sfw/lib/amd64 -L/usr/lib/amd64 -L/opt/sfw/lib -o RPostgreSQL.so | RS-DBI.o RS-PostgreSQL.o -L/usr/lib -lpq | ld: fatal: file /usr/lib/libpq.so: wrong ELF class: ELFCLASS32 | ld: fatal: File processing errors. No output written to RPostgreSQL.so The linker complained about bad objkect files. Looks like you have a wrong or mismatched Pg library. We'd have to fix that first before RPostgreSQL can be built. Also ask Greenplum if they can help. At least they get paid for this :) Dirk | *** Error code 1 | The following command caused the error: | if test zRS-DBI.o RS-PostgreSQL.o != z; then \ | echo /opt/sunstudio12.1/bin/cc -m64 -xc99=all -G -L/opt/R/R2-11-1/lib | -L/usr/sfw/lib/amd64 -L/usr/lib/amd64 -L/opt/sfw/lib -o RPostgreSQL.so | RS-DBI.o RS-PostgreSQL.o -L/usr/lib -lpq ; \ | /opt/sunstudio12.1/bin/cc -m64 -xc99=all -G -L/opt/R/R2-11-1/lib | -L/usr/sfw/lib/amd64 -L/usr/lib/amd64 -L/opt/sfw/lib -o RPostgreSQL.so | RS-DBI.o RS-PostgreSQL.o -L/usr/lib -lpq ; \ | fi | make: Fatal error: Command failed for target `RPostgreSQL.so' | ERROR: compilation failed for package 'RPostgreSQL' | * removing '/opt/R/R2-11-1/lib/R/library/RPostgreSQL | | On Sun, Jul 18, 2010 at 10:50 PM, ¹ËС²¨ guxiaobo1...@gmail.com wrote: | | Hi, | I have successfully built and installed DBI and RPostgreSQL on 32bit | Solaris, and will repeat in on our 64bit production server tomorrow, I'll | let you know the results. | | We still waiting for the building toolset for win64 to mature. | | Xiaobo.Gu | | | -Original Message- | From: Dirk Eddelbuettel [mailto:e...@debian.org] | Sent: Sunday, July 18, 2010 9:59 PM | To: ¹ËС²¨ | Cc: 'Dirk Eddelbuettel'; 'Uwe Ligges' | Subject: RE: Package RPostgreSQL_0.1-6.tar.gz has been checked and built | | | Hi again, | | On 18 July 2010 at 21:41, ¹ËС²¨ wrote: | | Hi Dirk, | | We have tested RPostgreSQL against 64bit RODBC both on the same | 64bit Windows Server. | | | | The
Re: [Rd] Package ff building error on solaris x64 10u7
Thanks, this one works 2010/7/20 Prof Brian Ripley rip...@stats.ox.ac.uk This is a known problem, reported to the maintainer months ago. Try http://www.stats.ox.ac.uk/pub/RWin/GPLcompliance/ff_2.1-2.1.tar.gz [You will be able to see which 100+ packages fail on Solaris from the CRAN package check pages.] And please try to send properly formatted text messages: we really don't want to read double-spaced output. On Tue, 20 Jul 2010, ¹ËС²¨ wrote: Hi again, I am trying to building ff on solaris x64 10u7, and failed with the following result: -bash-3.00$ R CMD INSTALL ff * installing to library '/opt/R/R2-11-1/lib/R/library' * installing *source* package 'ff' ... checking for gcc... /opt/sunstudio12.1/bin/cc -m64 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... no checking whether /opt/sunstudio12.1/bin/cc -m64 accepts -g... yes checking for /opt/sunstudio12.1/bin/cc -m64 option to accept ISO C89... none needed checking how to run the C preprocessor... /opt/sunstudio12.1/bin/cc -m64 -E checking for grep that handles long lines and -e... /usr/sfw/bin/ggrep checking for egrep... /usr/sfw/bin/ggrep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/vfs.h usability... yes checking sys/vfs.h presence... yes checking for sys/vfs.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking for sys/stat.h... (cached) yes checking for unistd.h... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/mount.h usability... yes checking sys/mount.h presence... yes checking for sys/mount.h... yes checking for struct statfs.f_iosize... no checking sys/statfs.h usability... yes checking sys/statfs.h presence... yes checking for sys/statfs.h... yes checking for struct statfs.f_iosize... (cached) no checking sys/statvfs.h usability... yes checking sys/statvfs.h presence... yes checking for sys/statvfs.h... yes checking for off_t... yes checking for size_t... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for _LARGEFILE_SOURCE value needed for large files... no checking for fseeko... yes configure: creating ./config.status config.status: creating src/ac_config.h ** libs /opt/sunstudio12.1/bin/CC -m64 -lCrun -I/opt/R/R2-11-1/lib/R/include -I/opt/R/R2-11-1/include -I/usr/sfw/include -I/opt/sfw/include -I/usr/openwin/share/include-KPIC -xO3 -c Error.cpp -o Error.o /opt/sunstudio12.1/bin/CC -m64 -lCrun -I/opt/R/R2-11-1/lib/R/include -I/opt/R/R2-11-1/include -I/usr/sfw/include -I/opt/sfw/include -I/usr/openwin/share/include-KPIC -xO3 -c FSInfo_statfs.cpp -o FSInfo_statfs.o FSInfo_statfs.cpp, line 50: Error: Could not find a match for statfs(const char*, statfs*) needed in ff::getFSInfo(const char*, ff::FSInfo). FSInfo_statfs.cpp, line 52: Error: f_bavail is not a member of statfs. FSInfo_statfs.cpp, line 53: Warning: The variable sfs has not yet been assigned a value. 2 Error(s) and 1 Warning(s) detected. *** Error code 2 make: Fatal error: Command failed for target `FSInfo_statfs.o' ERROR: compilation failed for package 'ff' * removing '/opt/R/R2-11-1/lib/R/library/ff' -bash-3.00$ [[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 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] broken link to new features in R-devel: no NEWS file
On Tue, Jul 20, 2010 at 10:20 PM, mark.braving...@csiro.au wrote: Hi The link from CRAN to new features in R-devel hasn't been working for a few days. Specifically, there is no NEWS file in https://svn.r-project.org/R/trunk/, though there is an ONEWS. The link is in the Source code for all platforms subwindow, where it says: Daily snapshots of current patched and development versions are available here. Please read about new features and bug fixes before filing corresponding feature requests or bug reports. It seems now to be at: https://svn.r-project.org/R/trunk/doc/NEWS.Rd __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
