similar to: R-alpha: Second patch for 0.50-a1

A set of patches for R-0.50-a1 is now available as ftp://stat.auckland.ac.nz/pub/R/R-0.50-a1.patch1.gz The patches mainly fix problems reported since R-0.50-a1 but some older problems are also fixed. Here is the list of changes. Ross o Many subsetting and mutation problems with the new "expression" type have now been fixed. o When ask=T is set in par() the user is instructed

Problems in R but not in S: --------------------------- 1) 'unlist' seems to have several other problems than the ones reported up to now. For instance, 'unlist' can be used on almost any object in S without much trouble. Eg.: S> unlist(c(2)) [1] 2 S> --- R> unlist(c(2)) Segmentation fault (core dumped) This occurs in R-0.49 and in R-0.50-a1. 2) Problem with the

>>>>> Thomas Lumley writes: > On Fri, 1 Aug 1997, Kurt Hornik wrote: >> Thomas, >> >> Could you add the "-lf2c" at the end of the line >> @$(LD) $(SHLIBLDFLAGS) -o $(LIBNAME).so $(OBJS) >> in acepack's src-c/Makefile? >> >> I ran across an identical pow_dd problem recently with another package. >> Did we always need

Hi, all. In trying to compile R v.0.90 on an alpha running Red Hat Linux 6.0, I'm getting the following error: make[3]: Entering directory `/home/mcw/alpha-R/R-0.90.0/src/appl' gcc -I. -I../include -I../../src/include -DHAVE_CONFIG_H -mieee -g -O2 -c cpoly.c -o cpoly.o /tmp/ccPjZNwd.s: Assembler messages: /tmp/ccPjZNwd.s:312: Error: unknown opcode `sqrttsu' /tmp/ccPjZNwd.s:2631:

Hi, I'm attempting to compile R 2.7.0 on my G5, which is running OSX 10.5.2. Yes, I know there is a precompiled binary, but my experience has shown that if I hand-compile ATLAS on my machine and then link R against it when compiling, R runs faster, hence me compiling it myself. Anyway, I have this set of errors: checking X11/Intrinsic.h usability... no checking X11/Intrinsic.h presence...

Two things. TASKS has TASK: Naming with Numeric Values and "unlist" STATUS: Open FROM: <hornik@ci.tuwien.ac.at> R> l <- list("11" = 1:5) R> l $11 [1] 1 2 3 4 5 R> unlist(l) 111 112 113 114 115 1 2 3 4 5 [ Bug or feature ? ] This seems to be a feature (at least, SPLUS does the same), so please close that task. *** However, please add

Here's a trivial patch (Martin!). -k --- src/library/base/man/Arithmetic.orig Tue Aug 5 22:33:16 1997 +++ src/library/base/man/Arithmetic Tue Aug 5 22:35:51 1997 @@ -15,6 +15,7 @@ ALIAS(^) ALIAS(%%) ALIAS(%/%) +ALIAS(Arithmetic) VALUE( These binary operators perform arithmetic on vector objects. They return numeric vectors containing the result of the element

Can anyone spot the problem here. Following is an edited script of the install session. The gist is: * syntax error in original src/main/dotcode.c Easily remedied (or at least, such that compiles without error message ... ) change line 449-450 (two lines preceding return) #ifdef HAVE_F77_UNDERSCORE if(PRIMVAL(op)) { *q++ = '_'; *q = '\0'; #endif }

>> I'm a bit confused about this discussion, but since I don't have f2c on ... >A lot of Fortran code doesn't require any libf2c routines. When routines >are needed the most common ones are the exponentiation routines pow_dd, >pow_ii and pow_di (pow_ri is for single precision reals and so is less >needed in R, which uses double precision). However, *some* fortran

In CHANGES, it says ------------------------------------------------------------ >> BUG FIXES ........ >> o Comments are handled better in functions. The rule is that they >> are shifted to just before their statements. Comments after the >> last statement of a function are lost. ------------------------------------------------------------ I think we could

Thanks for fixing formula() and update(). Here are some open problems. * effects: ** There is no help available for effects() ** The lm() help page has effects(lm.obj), but from the code it is clear that the one-arg version cannot work. Shouldn't it simply return z$effects? ** The two-arg version only works for factors (?) ... otherwise, z$model.frame[factors & pattern != 0] gives

The current version of S_alloc in src/main/memory.c is char *S_alloc(long nelem, int eltsize) { unsigned int i, size; char *p = R_alloc(nelem, eltsize); for(i=0 ; i<size; i++) p[i] = 0; return p; } which segfaults because `size' is not initialized. I am not what the right fix is, adding size = nelem * eltsize; before the loop seems to work. As an aside ... I think the seed*

Here's something really strange. ******************************************************** R> x <- 1:5 R> x [1] 1 2 3 4 5 R> test1 function (x) { structure(x, call = sys.call()) } R> test1(x) [1] 1 2 3 4 5 attr(,"call") test1(x) R> test2 function (x) { attr(x, "call") <- sys.call() x } R> test2(x) Error: stack overflow

Applying the following patches closes the following task (part 1 was already taken care of). TASK: New Problems STATUS: Open FROM: <Kurt.Hornik@ci.tuwien.ac.at> New minor remarks: * The documentation for `image' still has the old order z, x, y. * Perhaps one should add `par(ask = T)' in the image demo? * Perhaps one should save the original value

Here are some misc comments on graphics. * I am not sure whether `adj' works correctly. When using e.g. title(sub = "SUBTITLE", adj = 0) shouldn't the subtitle appear on the very left? It seems that justification is done off the middle of the plot window. * S barplot has argument `horiz', R does not. * More importantly, the barplot() argument `space' is treated

The patch below fixes the NChisquare documentation problem that I've been mentioning for some time now. NOTE: There is one DEQN where the LaTeX part contains real LaTeX code, because I did not see how to get a sum sign (and a roman math font) otherwise. Seems to work, though ... MARTIN? -k ********************************************************************** ***

Thanks to Brian Ripley, Douglas Bates, and Peter Dalgaard, who all pointed me towards the assembler (or compiler/assembler conflicts) as the likely culprit in my earlier "opcode" errors (most of original question below). After a lot of looking around, we found out that the particular alpha system we bought (from Microway) doesn't like the gnu compilers; it prefers Compaq's c

This message is in MIME format --_=XFMail.1.1.p0.Linux:971128122615:3052=_ Content-Type: text/plain; charset=us-ascii I have rounded up three buglets in R-0.50-a4. Two of them I can fix and a patch is supplied below. I hope this is useful for the current source (if these haven't been fixed already :) 1) cov cov() fails when it's argument is a matrix with one column and with column names

Batch: Putting q(save=F) at the end of my file does not work in my context because I can no longer source the file without quitting. I have that quit statement in my .First so that I always quit that way interactively. The problem is that it is ignored in batch. eigen: The crash occurs on my 586 running Red Hat Linux 2.0.27 but not on my son's 486 running SLackware Linix 2.0.29. We both

eigen(matrix(rep(1,9),ncol=3),only.values=T) works repeatedly but eventually (after 3 or 4 goes) gave a core dump of 11mb (I think only the first answer was right). if I type gc() immediately after the first call, I get a core dump right away (this might possibly be related to my huge core dumps with nlm) eigen(matrix(rep(1,9),ncol=3)) core dumps immediately after the first call Jim