similar to: configuration options for Alpha

Hi, I've found that the default options of gcc and g77 on alpha produce an executable that suffers from floating exceptions. There seems to be a problem with the configure scripts that prevents the --with-f77 option working correctly. The configure script tests that f77 is running by attempting to compile and link a dummy program - the link step seems broken on the alpha (it doesn't like

R ran find on our Sun until it was stolen. I have now set up R on one of our Dec Alphas OSF1 V4.0 386. R-0.49 configures builds and runs fine except that the glm command crashes R. R-0.60.1 configures builds and runs until a cis entered. I think the problem is the floating point conventions but before I get in over my head a question Has anyone used glm successfully on Alphas OSF1 V4.0 386?

Hello, I think this is a bug, although it is possible that I'm doind something silly. I want to be able to determine the argument name for variables passed to a generic print function suppose we have print.foo <- function(x, ...) { nm<-deparse(substitute(x)) cat("param name is ", nm, "\n") } d<-structure(1, class="foo") Under R-1.2.[2,3] >

Hi, I've been using Rprintf from a shared library compiled under various unix flavour for a while now. I get a warning about Rprintf being undefined when constructing the library, but everything works OK after loading. I've also been cross compiling the same library using the mingw32 tools for a while now, but the inclusion of Rprintf seems to be messing up this process. It can't

Hi All, I've done some work recently making some of our image analysis library callable from R and Splus. Most of the C image functions use an abstract data type, and R only sees a pointer to this. All memory allocation is done by the library. This leads to some interesting problems. I'm interested in your views about possible solutions. 1) assignment. something like a<-b, where a and

Running on an Alpha machine which reports (uname -a) OSF1 bsdx01.bs.ehu.es V4.0 878 alpha and using the binary distribution put together by Albrecht Gebhardt (in http://cran.at.r-project.org/bin/osf/osf4.0/tar/alpha_ev5/) I obtain core dumps whenever I try to use package rpart. I have R REMOVE'd the rpart package, downloaded the source rpart_1.0-7.tar from CRAN and

Hi, I've been developing an image analysis package based on R for a while now and I've had problems relating to garbage collection, so it with great interest that I've noticed the work done by Luke Tierney in this area, and I'd like to discuss how best to fit it into my package. I'll start with how my package is structured - an image is represented by an integer with a class

Hi All, I've done some work recently making some of our image analysis library callable from R and Splus. Most of the C image functions use an abstract data type, and R only sees a pointer to this. All memory allocation is done by the library. This leads to some interesting problems. I'm interested in your views about possible solutions. 1) assignment. something like a<-b, where a and

Hi, this relates to my earlier message about external references and finalizers. I was experimenting over the weekend and now suspect that the appropriate solution to my problem will be to have a special case in the code that handles the .C call so that external references are handled appropriately - I guess that a pointer to the reference should be passed to the C code. As I've never

Hi, I had some trouble compiling the new R version on my Alpha: make[2]: Entering directory `/usr2/local/R/src/graphics' cc -ieee_with_inexact -O -Olimit 2000 -I/usr/local/include -I../include -c gdevice.c cc -ieee_with_inexact -O -Olimit 2000 -I/usr/local/include -I../include -c graphics.c cc: Error: graphics.c, line 808: An unexpected newline character is present in a string literal.

Hi, I had some trouble compiling the new R version on my Alpha: make[2]: Entering directory `/usr2/local/R/src/graphics' cc -ieee_with_inexact -O -Olimit 2000 -I/usr/local/include -I../include -c gdevice.c cc -ieee_with_inexact -O -Olimit 2000 -I/usr/local/include -I../include -c graphics.c cc: Error: graphics.c, line 808: An unexpected newline character is present in a string literal.

I wrote about my problems building R-0.63.3 on a Digital Alpha running OSF V4.0D. Thanks to the suggestion Jonathan.Yuen at tvs.slu.se, I tried using the DEC CC compiler instead of gcc, and it worked just fine. (Seeing that I needed gmake to build, it never occured to me to try DEC CC. It seems that you cannot combine DEC F77 with gcc; I do not have g77 to try.) Below is a set of instructions

While termplot is under discussion, here's another proposal. I'd like to change the default for partial.resid to TRUE, and for smooth to panel.smooth. I'd be surprised if those changes were to break existing code. John Maindonald email: john.maindonald at anu.edu.au phone : +61 2 (6125)3473 fax : +61 2(6125)5549 Centre for Mathematics & Its Applications, Room

Hi, The following function use to work, but now it doesn't giving the error "> CallSnow(, 100) Using snow package, asking for 2 nodes 2 slaves are spawned successfully. 0 failed. Error in checkForRemoteErrors(val) : 2 nodes produced errors; first error: no applicable method for 'lapply' applied to an object of class "list" ". Where this is the

My apologies for he very short time before things close, but it's not my fault. If necessary get your hat in the ring by Friday and see to the niceties later, may I suggest. This is a vacancy in my group in Cleveland. The work is interesting and the challenges large. Bill Venables. ---------------------------------------------------------------------------- Division of Marine Research

Dear R-users, I currently have trouble in trying to compile R-1.3.0-patched on Compaq OSF1. -------- >uname -a OSF1 adenine.fysik.dtu.dk V4.0 1229 alpha -------- The 'configure' step ended seemingly corretly: ----------------------- R is now configured for alphaev6-dec-osf4.0f Source directory: . Installation directory: /home/adenine/sysman/laurent/share/ C

I am trying to install R-0.63.3 on a Digital Alpha running OSF V4.0D, and having some difficulties. Can anyone help? Also, I found some "oddities" in the installation process. I expect that this message is read by the developers, maybe some of my suggestions can be incorporated into future releases. Please reply to me directly (as well as possibly also to this mailing list): I am not a

I see Peter has just announced the release of 1.0.0, on time, even here in Australia, in accordance with a timetable privately announced about 6 months ago. At that time it seemed optimistic to put it mildly. I am not a member of the core team, but as an ordinary user of R with a more privileged inside view than most I'd like to offer my personal congratulations and thanks. This is the

Digital Alpha (various), Digital UNIX V4.0[EF], R-1.0.0, gcc, f77 When using batch mode with the save option, an error message is issued. However [I have just discovered that] it appears that the operation does complete, i.e. the .RData file is saved successfully. The main problem is that the return code is non-zero (and so it is impossible to distinguish this "non-error" from some

> I think we should get rid of source attributes completely, > since they are no longer needed, but your comment still > applies to source references. We should strip them when code > gets modified. > > Duncan Murdoch I would be very concerned about losing source attributes-- it would break a lot of my code :(! It's very useful to have a single portable R object that