[Rd] R 2.1.0 (beta) on IRIX
I'm trying to compile R-beta on IRIX using the native MipsPro 7.4 compilers, without great satisfaction. A list of problems is given below, and any advice on solving them is appreciated. Martyn Configuration: - Here are the configuration options I am using ./configure CC=cc CXX=CC F77=f77 CPPFLAGS=-I/usr/freeware/include LDFLAGS=-L/usr/freeware/lib32 CFLAGS=-g -O2 CXXFLAGS=-g -O2 FFLAGS=-g -O2 The CPPFLAGS and LDFLAGS are required for readline and NLS capabilities. The compilers are not optimized by default so you need to supply the relevant flags. Major problems: -- 1) inline function in src/extra/bzip2 The function BZ2_indexIntoF is declared inline in bzlib.c and extern in bzlib_private.h. The linker claims that the symbol is undefined. This can be solved by removing the R_INLINE keyword. I can't see another solution, and reading these guidelines on inlining ( http://www.greenend.org.uk/rjk/2003/03/inline.html ) leaves me no wiser. 2) IEEE arithmetic The standalone math library fails to compile, as the compiler chokes on the definition of ML_POSINF, ML_NEGINF and ML_NAN, e.g. cc-1195 cc: ERROR File = mlutils.c, Line = 130 The indicated floating-point operation result is out of range. double NA_REAL = ML_NAN; where ML_NAN is defined as (0.0 / 0.0) in nmath.h. The compiler flag -OPT:IEEE_NaN_inf=ON is supposed to enforce IEEE arithmetic but apparently isn't enough. Minor problems -- 3) Make IRIX make does not like continuation lines followed only by a comment. So, for example, these lines from src/appl/Makefile.in OBJECTS = $(SOURCES_C:.c=.o) $(SOURCES_F:.f=.o)\ @USE_EXTERNAL_BLAS_FALSE@ blas.o @COMPILE_DOUBLE_COMPLEX_FALSE@ zgemm.o which become OBJECTS = $(SOURCES_C:.c=.o) $(SOURCES_F:.f=.o) \ # blas.o zgemm.o in the Makefile, cause an error. I have worked around this by joining the two lines, but the problem recurs several times in the tests directory. I shall probably fall back on gmake. 4) Building in a setgid directory This isn't an IRIX-specific problem. The administrators provide some scratch space for temporary files in a setgid directory and I started building R here. All files have the group sys of which ordinary users are not members. This causes some difficulty with the installation of files in src/library/libname/inst/po. I can't give the exact error message as I have accidentally deleted the file in which I was making notes, but it's an ownership problem. 5) strptime The problem with strptime documented in the R-admin manual is still present on this system (release 6.5.27), although it is supposed to have been solved in release 6.5.22m. Briefly, is.na fails to recognize a valid POSIX time: strptime(1910/1/1, %Y/%m/%d) [1] 1910-01-01 is.na(strptime(1910/1/1, %Y/%m/%d)) [1] TRUE I have not tried the suggested work-around yet. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] HP-UX and IRIX recent builds? Any other rare platforms?
I have just (this week) got access to an SGI Origin running IRIX 6.5.27. In answer to your previous questions about locales, locale -a shows no utf8 locales; mbrtowc and wcwidth are defined in wchar.h. Compiling R with the native compilers looks problematic. If I find the right compiler flags I will let you know. Martyn On Wed, 2005-04-06 at 09:07 +0100, Prof Brian Ripley wrote: I am revising the section in R-admin on platforms. When I asked about locales earlier this year I got no reply about HP-UX and IRIX, so I will presume that no one has built R on those OSes recently. If you have, please send me the OS number and the flags you used. Platforms where I have seen recent reports: Linux MacOS X Solaris 8, 9, 10 (any Solaris 7 users please let me know) AIX 5.1 and 5.2 FreeBSD and less recently, OSF/1. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] make error in R devel
If you get the R source via svn, then you need to run tools/rsync- recommended to get the recommended packages. If you download the tarball from CRAN then these are already included. Martyn On Wed, 2005-04-06 at 15:42 +0100, Gavin Simpson wrote: Dear list, I just hit an error that stopped my make make check-devel operation on my linux box (FC3, i686 P4 2GB RAM). Just to note that I've been building the development branch(?) for some time and this is the first hint of a problem. 1) updated the src tree using svn update 2) ran ../configure --with-recommended-package=no from my build directory 3) got: R is now configured for i686-pc-linux-gnu Source directory: ../src Installation directory:/usr/local C compiler:gcc -O3 -g -march=i386 -mcpu=i686 C++ compiler: g++ -O3 -g -march=i386 -mcpu=i686 Fortran compiler: g77 -O3 -g -march=i386 -mcpu=i686 Interfaces supported: X11, tcltk External libraries:readline, BLAS(generic) Additional capabilities: PNG, JPEG, iconv, MBCS, NLS Options enabled: R profiling Recommended packages: no Note I've editted config.site to compile with optimisations -O3 4) did make make check-devel and get this: ... make[5]: Entering directory `/home/gavin/R/devel/build/src/library' Building/Updating help pages for package 'graphics' Formats: text html latex example make[5]: Leaving directory `/home/gavin/R/devel/build/src/library' running code in 'graphics-Ex.R' ... OK collecting examples for package 'stats' ... make[5]: Entering directory `/home/gavin/R/devel/build/src/library' Building/Updating help pages for package 'stats' Formats: text html latex example make[5]: Leaving directory `/home/gavin/R/devel/build/src/library' running code in 'stats-Ex.R' ...make[4]: *** [stats-Ex.Rout] Error 1 make[4]: Leaving directory `/home/gavin/R/devel/build/tests/Examples' make[3]: *** [test-Examples-Base] Error 2 make[3]: Leaving directory `/home/gavin/R/devel/build/tests/Examples' make[2]: *** [test-Examples] Error 2 make[2]: Leaving directory `/home/gavin/R/devel/build/tests' make[1]: *** [test-all-basics] Error 1 make[1]: Leaving directory `/home/gavin/R/devel/build/tests' make: *** [check-devel] Error 2 5) Looking at stats-Ex.Rout.fail I see this at the end: ### Name: confint ### Title: Confidence Intervals for Model Parameters ### Aliases: confint confint.default ### Keywords: models ### ** Examples fit - lm(100/mpg ~ disp + hp + wt + am, data=mtcars) confint(fit) 2.5 % 97.5 % (Intercept) -0.774822875 2.256118188 disp-0.002867999 0.008273849 hp -0.001400580 0.011949674 wt 0.380088737 1.622517536 am -0.614677730 0.926307310 confint(fit, wt) 2.5 % 97.5 % wt 0.3800887 1.622518 ## from example(glm) counts - c(18,17,15,20,10,20,25,13,12) outcome - gl(3,1,9); treatment - gl(3,3) glm.D93 - glm(counts ~ outcome + treatment, family=poisson()) confint(glm.D93) Error in loadNamespace(name) : there is no package called 'MASS' Execution halted But as there are no recommended packages this fails as indicated. So is there something wrong with what I'm doing (i.e. something recent in the last week has changed that I missed in NEWS) or is this a bug in the tests or examples? Cheers Gav __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linux: /usr/shar/doc/R-2.0.1/*.pdf all have bad fonts (PR#7677)
I have forwarded the message to Matthew Cox, who built the RPMS for Red Hat Enterprise Linux. But if you get the same problem building from source then it must be a platform-specific problem and you should probably get support from Red Hat. Martyn On Wed, 2005-02-09 at 08:32 +0100, [EMAIL PROTECTED] wrote: Please report this to the RPM provider: it is not true of R in general. This is the R bug repository, not the CRAN error address. On Wed, 9 Feb 2005 [EMAIL PROTECTED] wrote: Full_Name: Bruce Foster Version: 2.0.1 OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 4) Submission from: (NULL) (129.105.110.38) All of the pdf files in /usr/share/doc/R-2.0.1 from the CRAN RedHat RPM have invalid fonts. A build from source yields the same problem. [EMAIL PROTECTED] R-2.0.1]# ll *.pdf -rw-r--r--1 root root 259886 Nov 19 10:50 R-FAQ.pdf -rw-r--r--1 root root 127067 Nov 19 10:50 R-admin.pdf -rw-r--r--1 root root 143761 Nov 19 10:50 R-data.pdf -rw-r--r--1 root root 374269 Nov 19 10:50 R-exts.pdf -rw-r--r--1 root root 435252 Nov 19 10:50 R-intro.pdf -rw-r--r--1 root root 268142 Nov 19 10:50 R-lang.pdf The files are unreadable with xpdf and acroread, and pdf2ps shows this: [EMAIL PROTECTED] R-2.0.1]# pdf2ps R-admin.pdf Error: /invalidfont in /F72 Operand stack: --dict:5/5(L)-- F72 20.659 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop --nostringval-- 2 1 29 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- --nostringval-- %array_continue --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1051/1123(ro)(G)-- --dict:0/20(G)-- --dict:92/200(L)-- --dict:92/200(L)-- --dict:97/127(ro)(G)-- --dict:229/230(ro)(G)-- --dict:19/24(L)-- --dict:4/6(L)-- --dict:23/31(L)-- Current allocation mode is local GNU Ghostscript 7.05: Unrecoverable error, exit code 1 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tapply with weighted.mean
We were caught out recently attempting to use tapply to get a table of weighted means. This gives the wrong answer (or, more correctly, not the answer we were expecting), as the following example shows: R x - 1:10 #some data R w - c(1:5,5:1) #weights R id - rep(1:2,rep(5,2)) #id values R weighted.mean(x[id==1],w[id==1]) #Weighted mean of x in group 1 [1] 3.67 R weighted.mean(x[id==2],w[id==2]) #Weighted mean of x in group 2 [1] 7.33 R tapply(x,INDEX=id,FUN=weighted.mean,w=w) #Wrong! 1 2 3 8 The reason for this is that tapply splits it's first argument by the INDEX variable, but does not split any of the arguments supplied via ... So the result is c(weighted.mean(x[id==1],w), weighted.mean(x[id==2],w)) R silently replicates the shorter variable to match the length of the longer one. I draw two conclusions from this: 1) weighted.mean(x,w) should include a length check for w. The documentation says it should be the same length as x, so this should be enforced. 2) More importantly, the help page for tapply should explicitly warn the user that optional arguments supplied to 'FUN' are not split by 'INDEX'. I really only understood the behaviour of tapply after inspecting the code. Then it became obvious why this could never work. I hope I am not being too obtuse. Any objections before I make these changes? Martyn __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Standalone Mathlib, C++ and ISNAN()
On Thu, 2005-01-06 at 08:29 +1100, Bill Northcott wrote: On 06/01/2005, at 6:53 AM, Thomas Lumley wrote: I believe (with a little Googling) the suggested C++ approach is to use std::isnan if cmath is included. I tried that too, but without any success. I even tried __gnu_cxx::isnan. It was suggested by one of the gcc people, but I could find no documentation about it. The ISO C++ docs do not include isnan as a symbol provided by cmath within the std namespace. I looked at the gcc source code and could see no reason why it should work. I think the workaround is supposed to look like this: #define _GLIBCPP_USE_C99 1 #include cmath #undef _GLIBCPP_USE_C99 #include iostream using __gnu_cxx::isnan; I don't know whether this solves the problem on MacOs X but it is valid on Linux. But do you really want to write code that is specific to gcc? I don't. Martyn __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] binary R for Fedora Core 2 e tcl
On Tue, 2004-05-25 at 13:04, [EMAIL PROTECTED] wrote: I update my linux version of FC1 for FC2. FC2 uses tcl-8.4.5 and R-1.9.0 (rpm version for FC1, not install/not run). We have the rpm binary version at FC2? Not yet. I was going to upgrade, but then Marc Schwartz pointed out this show-stopping bug, which may destroy your ability to dual-boot windows (as I still do) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115980 I have FC2 installed on a test machine. The X server appears to be quite buggy (this should be no surprise as R has already been patched to work around one bug) and I have some difficulty getting the NIC to work, so I am not very impressed. Bottom line: If you use FC2 then you are on the bleeding edge, and quite possibly over it. I'll try to get RPMs ready for R 1.9.1 but I'm not going to hose any of my production machines for your benefit. Martyn __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot.factor does not work properly (PR#6894)
On Tue, 2004-05-18 at 16:46, [EMAIL PROTECTED] wrote: Full_Name: Xavier Sole Version: 1.9.0 OS: Windows XP/SuSe Linux Submission from: (NULL) (146.219.19.22) plot.factor in 1.9.0 shows different results than in R 1.8. Only one bar is displayed. plot(factor(rep(1:3,10))) I think this is the same as PR#6776 Martyn __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cygwin tar?
I had the same problem as Tony with multiple copies of cygwin1.dll. But
doesn't this solution (renaming cygwin1.dll in the tools directory) just
link the tools with the cygwin1.dll that comes with cygwin? In which
case will it work if the tools are linked against a different version of
the cygwin1 library?
To answer Jeff's question
if($WINDOWS) {
## workaround for paths in Cygwin tar
$filepath =~ s+^([A-Za-x]):+/cygdrive/\1+;
}
in the build script and don't think it needs to be there since you can
use the tar utility that comes with mingw, yes?
You're talking about the tar that comes with MSYS. And no you can't use
it because it can't handle symbolic links, a problem that is discussed
in the documentation.
On Tue, 2004-03-16 at 20:23, Tony Plate wrote:
Jeff: alternatively, I don't think it's necessary to completely remove a
cygwin installation in order to use MinGW and build R.
What I have done to build R from a bash cygwin window under Windows 2000:
(1) put the tools directory and the MinGW directories ahead of any cygwin
directories on the path
(2) rename the cygwin1.dll that was in the tools directory (from Brian
Ripley's tools.zip) to something like Xcygwin1.dll (to avoid cygwin
conflicts)
I also have ActiveState Perl installed and ahead of the cygwin perl on the
path (though I have a wrapper for it that translates cygwin paths on the
command line to windows paths).
This configuration is different from the instructions in
src/gnuwin32/INSTALL in that I don't use the cygwin1.dll from
tools.zip. However, since updating some things recently, having
cygwin1.dll in the tools directory always resulted in the cygwin1.dll
conflict error, even when I changed the PATH to not have any other version
of cygwin1.dll on it.
This may or may not work for anyone else, but it seems to be working for me
at the moment: I can build R and the recommended packages from source and
run the tests.
-- Tony Plate
At Tuesday 11:32 AM 3/16/2004, Jeff D. Hamann wrote:
I've been attempting to create a new R package and recently removed the
cygwin installation from my machine since R requires the use of the MingW
tools for building an R package with C code. However, when I tried to build
a source package, I found the following results:
* removing junk files
* building 'Rconifers_0.7-1.tar.gz'
tar: /cygdrive/C/usfs/psw_redding/software/current/Rconifers_0.7-1.tar:
Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
tar: /cygdrive/C/usfs/psw_redding/software/current/Rconifers_0.7-1.tar:
Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
tar: /cygdrive/C/usfs/psw_redding/software/current/Rconifers_0.7-1.tar:
Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
Rconifers_0.7-1.tar: No such file or directory
C:\usfs\psw_redding\software\current
which looks like the cygwin path is hard coded into the build script for the
rcmd. I found the
if($WINDOWS) {
## workaround for paths in Cygwin tar
$filepath =~ s+^([A-Za-x]):+/cygdrive/\1+;
}
in the build script and don't think it needs to be there since you can use
the tar utility that comes with mingw, yes? I replaced the previous chunk of
code with:
if($WINDOWS) {
## workaround for paths in Cygwin tar
$filepath =~ s+^([A-Za-x]):+/\1+;
}
which has solved the problem. I just don't know how to get this into the
latest build or release of R?
Jeff.
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
