Re: [Rd] suppressing "global" cppflags in an individual package
Kasper, On May 11, 2006, at 12:37 AM, Kasper Daniel Hansen wrote: > Thank you Simon, a little comment below > > On May 9, 2006, at 2:49 PM, Simon Urbanek wrote: > >> On May 9, 2006, at 1:11 PM, Kasper Daniel Hansen wrote: >> >>> It is indeed the case that after updating to GCC 4 the package >>> gets broken using -O2. I agree this needs to be fixed, but the >>> error >>> [...] >>> unfortunately), but reading your comment about CPPFLAGS and >>> CXXFLAGS makes me think I can indeed override it using the >>> package Makevars file. The flags I was passing to the compiler >>> were library locations anyway which was for the preprocessor. >>> >> >> AFAIR you cannot override CPPFLAGS/CXXFLAGS in Makevars, because >> it gets included first. You can, however, use something like this: >> >> all: $(SHLIB) >> >> MYCFLAGS=-O0 >> >> %.o: %.c >> $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) $(MYCFLAGS) -c $< -o $@ >> >> for C, or for C++ accordingly: >> >> %.o: %.cc >> $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $(MYCXXFLAGS) -c $< >> -o $@ > > Actually you do not need the all: line, and since I use .cpp as C++ > extension, all I needed was > > %.o: %.cpp > $(CXX) $(ALL_CPPFLAGS) -O0 -c $< -o $@ > If it worked for you, fine ... but it doesn't for me (using plain SHLIB), because you're replacing the first target, the .so doesn't get built. > Note that I needed to delete the $(ALL_CXXFLAGS) which basically > reads R's flags. > Well actually the point was that you *don't* need to do that and you should not. Most compilers (including gcc) ignore preceding conflicting flags, so -O3 -O0 will give you simply -O0 and that's what you wanted. > Now, is there any way to (in the Makevars file) operate on $ > (ALL_CXXFLAGS), since all I want is to delete any -O* flag? Or is > defining rules and variables all I can do? > Yes. Again, I'm talking GNU make now, so I suspect this is not portable (so kids, don't do this at home), but you should be able to use MYCXXFLAGS=$(filter-out -O3,$(ALL_CXXFLAGS)) However as stated above I don't think you want to do that - just append -O0 and you're safe. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 2.3.0 make install fails on solaris
This is already changed in R-patched: please use that.
On Wed, 10 May 2006, Peter Dalgaard wrote:
> Darin Perusich <[EMAIL PROTECTED]> writes:
>
>> hello r development team,
>>
>> i'm building R 2.3.0 on solaris and when i run the 'make install' i'm
>> getting a syntax error during the "installing etc ..." which causes the
>> installation to fail. i get this error whether i use gnu-make of
>> sun-make, see the error and reasons below.
>>
>> gmake[1]: Entering directory `/export/medusa/darin/build/R-2.3.0/etc'
>> installing etc ...
>> /bin/bash: -c: line 1: syntax error near unexpected token `;'
>> /bin/bash: -c: line 1: `for f in ; do /opt/csw/bin/ginstall -c -m 644
>> ${f} "/export/home/darin/build/R-2.3.0/cswstage/opt/csw/lib/R/etc"; done'
>> gmake[1]: *** [install] Error 2
>> gmake[1]: Leaving directory `/export/medusa/darin/build/R-2.3.0/etc'
>> gmake: *** [install] Error 1
>>
>> in etc/Makefile if i comment lines 60-62 make install continues without
>> incident, here are those lines.
>>
>> @for f in $(EXPORTFILES); do \
>>$(INSTALL_DATA) $${f} "$(rhome)/$(subdir)"; \
>> done
>>
>> this has changed from R-2.2.1.
>>
>> diff etc/Makefile ../R-2.2.1/etc/Makefile"
>>
>> 60c52
>> < @for f in $(EXPORTFILES); do \
>> ---
>> > @for f in $(OBJECTS) $(EXPORTFILES); do \
>>
>> should i open a bug for this issue? i'm also curious as to if this has
>> come up on other platforms.
>
> It only happens if your bash is old enough. I get the
>
> rubin:~/> for f in ; do echo $f ; done
> bash: syntax error near unexpected token `;'
> rubin:~/>help
> GNU bash, version 2.05.0(1)-release (sparc-sun-solaris2.9)
> for f in ; do echo $f ; done
>
> but not on Linux boxes with bash 3.x. However, I don't think we assume
> bash 3.x (or bash as such for that matter and sh has same issue on
> Solaris 9), so it is indeed a bug.
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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] Allowed quasibinomial links (PR#8851)
This was already corrected in R-devel (including allowing cauchit): I have
moved the relevant part of the fix to R-patched now.
On Wed, 10 May 2006, [EMAIL PROTECTED] wrote:
> Full_Name: Henric Nilsson
> Version: 2.3.0 Patched (2006-05-09 r38014)
> OS: Windows 2000 SP4
> Submission from: (NULL) (83.253.9.137)
>
>
> When supplying an unavailable link to `quasibinomial', the error message looks
> strange. E.g.
>> quasibinomial("x")
> Error in quasibinomial("x") : 'x' link not available for quasibinomial family,
> available links are "logit", ", ""probit" and "cloglog"
>
> Clearly, something's missing. A quick peek in the code reveals that `log' is
> allowed, but is missing from the above list.
>
> Furthermore, shouldn't `quasibinomial' also allow the `cauchit' link?
--
Brian D. Ripley, [EMAIL PROTECTED]
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] (PR#8824) wishlist: summary for regression models to report
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-1097610713-1146500823=:15100 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: <[EMAIL PROTECTED]> You are apparently unaware that 'na.action' is an argument to lm (which defaults to the value of an option), and need not only take the value 'na.omit'. Your request does not make sense for other possible 'na.action's except 'na.exclude' (for example those which impute). However, there is already a mechanism provided for giving a suitable message, naprint(), so all you need to do is to instruct the audience of your sermon how to make use of it. You might do better to tell them to use na.action=na.fail (as S does and as I advise my students to do), and perhaps also to discuss developments in the field in the last 50 years. For 2.4.0-to-be I have added a line of output in the print.summary.[g]lm methods that will add to the information on degrees of freedom based on naprint(). On Mon, 1 May 2006, [EMAIL PROTECTED] wrote: > Full_Name: Ulrike Grömping > Version: 2.3.0 > OS: Windows > Submission from: (NULL) (84.190.150.205) > > > Whenever any observations are excluded from a regression analysis (lm, > glm, and other similar procedures) because of missing values, I would > find it very useful if this fact is directly visible from the output. I > think that the information should not only be available (I can e.g. look > at length of the na.action element of the lm object) but that a serious > statistical software should draw users' attention to the fact that > observations have been excluded. R is nothing like so dictatorial, but does already provide the tools for this viewpoint (as well as for others). > For convenience, it would also be nice in general if the number of > observations used in the analysis is indicated (for lm it is of course > possible but a bit awkward to find this number in case of many > parameters). (It is in fact very easy to find: see e.g. the code for logLik.lm.) > I hope that this will be implemented because it is quite easy to do (as > far as I can see). It would make it easier for students and applied > researchers to comply with my preaching to always report on the number > of valid observations and the portion of values excluded for > missingness. If you want something added to R, please be prepared to contribute a patch for it. (I believe you could have learned a lot from doing so, including about what is already provided.) -- Brian D. Ripley, [EMAIL PROTECTED] 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 --27464147-1097610713-1146500823=:15100-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question about match.fun()
On Tue, 9 May 2006, Berwin A Turlach wrote: > Dear all, > > I was recently contacted by a user about an alledged problem/bug in > the latest version of lasso2. After some investigation, we found out > that it was a user error which boils down to the following: > >> x <- matrix(rnorm(200), ncol=2) >> var <- "fred" >> apply(x, 2, var) > Error in get(x, envir, mode, inherits) : variable "fred" of mode "function" > was not found > > only that the "offending" apply() command happened inside the gl1ce() > function of lasso2. > > I was under the impression that R can now distinguish between > variables and functions with the same name and, indeed, the following > works: > >> var <- 2 >> apply(x, 2, var) > [1] 1.053002 1.250875 > > Poking a bit around, I guess that the ability to distinguish between > variables and functions with the same name comes from the introduction > of the function match.fun() and, after reading its help page, the No, not really. It comes in general from the internal C functions knowing from the context what they are looking for from the parse context. > reasons why an error is triggered the first time but not the second > time is perfectly clear to me. > > I wonder whether it would make sense to change match.fun() such that > the first case does not result in an error? I was thinking along the > line that if the argument to match.fun() is a variable that contains a > character vector of length one then, using get(), match.fun() attemps > to find a function with that name. If the get() command does not > succeed, then a second try is made using the name of the variable > passed by the caller to match.fun(). This is tricky, and indeed the bit that appears strange to me is that the second works. It comes from r5628 | pd | 1999-08-26 14:31:42 +0100 (Thu, 26 Aug 1999) | 2 lines match.fun fixes which is not very informative, but I found e.g. http://tolstoy.newcastle.edu.au/R/help/99b/0254.html PD> This also applies (!) to various other places that need to deal PD> with FUN arguments (apply, sapply, sweep, outer). It might be PD> preferable to make match.fun smarter, at the expense of making it PD> completely obscure. (and I think we succeeded!) The essence of that example would appear to be xlev <-list(a=1:7, length=NULL) sapply(xlev, is.null) which failed long, long ago. Note that ?apply (and so on) in 2.3.0 only mention the possibility of supplying a function or a character string. Even the latter seems unnecessary these days now we have backquotes: x <- matrix(runif(20), 10, 2) apply(x, 2, `+`, 7) I spent some time recently tidying up the family functions in R-devel. There the issues are similar but complicated by the fact that in binomial(probit) there is no object `probit'. I've come to the view that we are trying too hard in many of these cases. So I would like to see arguments why we need to allow more than function symbol length-one character vector. and I don't see it lessens the confusion to allow the name of a length-one character vector to mean either the value of the first element of the object or a symbol if the value is not visible as a function. > So before trying to modify match.fun() and submitting a patch, I > wanted to ask whether such a change would be accepted? Is there an > argument that I don't see that the first case should always result in > an error and not be silently resolved? The main argument is that it is not as documented, and confusing. -- Brian D. Ripley, [EMAIL PROTECTED] 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] S4 initialize methods, unexpected recursive callNextMethod
It's a bug resulting from the combination of:
1. multiple recursive levels of callNextMethod()
2. nonstandard arguments in the method definition; that is, (.Object,
x) vs .Object, ...) for the generic.
Specifically, the callNextMethod code tries to build up a list of
"excluded" classes, but in this example seems to fail. So the
nextMethod selected for class "B", when it goes to find the next^2
method, forgets to exclude class "C"; hence it goes back to the "C"
method & so infinite recursion.
To see what's happening, use trace(callNextMethod, recover) or equivalent.
The computation in addNextMethod, callNextMethod, etc. is all very
heuristic (aka "kludgey") code, so it's not clear how easy a fix would
be. The desirable route would be a better treatment of nonstandard
arguments, but that may require digging deeper into the R evaluator than
I've had the nerve to do so far.
Meanwhile, a work around is to avoid mechanism 2 if you want to use
mechanism 1. This may require separating out the guts of each method
from the callNextMethod() part, with that part coming in a method
definiton with standard arguments.
With the alternative definition below, all is well (if not very useful):
> new("C", a=1,b=2,c=3)
in C
in B
in A
An object of class "C"
Slot "c":
[1] 3
Slot "b":
[1] 2
Slot "a":
[1] 1
using the methods:
setMethod("initialize", signature(.Object="A"),
function(.Object, ...) {
cat("in A\n")
callNextMethod()
})
setMethod("initialize", signature(.Object="B"),
function(.Object, ...) {
cat("in B\n")
callNextMethod()
})
setMethod("initialize", signature(.Object="C"),
function(.Object, ...) {
cat("in C\n")
callNextMethod()
})
Seth Falcon wrote:
>Hi,
>
>Given a simple three class hierarchy: A <-- B <-- C
>
>I want to define an initialize method for each class such that when I
>call new("C", x=5), the initialize methods for A and B are used to
>incrementally build the object.
>
>When I do what seems obvious to me using callNextMethod, I get an
>infinite recursion. An example follows...
>
>setClass("A", representation(a="numeric"))
>setClass("B", representation(b="numeric"), contains="A")
>setClass("C", representation(c="numeric"), contains="B")
>
>setMethod("initialize", signature(.Object="A"),
> function(.Object, x) {
> cat("in A\n")
> [EMAIL PROTECTED] <- x
> .Object
> })
>
>setMethod("initialize", signature(.Object="B"),
> function(.Object, x) {
> cat("in B\n")
> .Object <- callNextMethod(.Object=.Object, x=x)
> [EMAIL PROTECTED] <- [EMAIL PROTECTED] + 1
> .Object
> })
>
>setMethod("initialize", signature(.Object="C"),
> function(.Object, x) {
> cat("in C\n")
> .Object <- callNextMethod(.Object=.Object, x=x)
> [EMAIL PROTECTED] <- [EMAIL PROTECTED] + [EMAIL PROTECTED] + 1
> .Object
> })
>
>
>## Works as I am expecting for B
>
>
>>myB <- new("B", 4)
>>
>>
>in B
>in A
>
>## When you create a C, the B method gets called but the appropriate
>## next method info seems lost and we end up back in C's method ?!
>
>
>>myC <- new("C", 5)
>>
>>
>in C
>in B
>in C
>in B
>in C
> C-c C-c
>
>Should this work? Is there a better way to organize the initializers
>for a simple hierarchy (perhaps assume that args to the initializers
>are not the same for A, B, and C).
>
>Thanks,
>
>+ seth
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug report - cor (PR#8852)
Full_Name: daniel t. O'Shea Version: 2.2.1 OS: xp Submission from: (NULL) (156.98.28.4) using the cor command in the base package. cor(x,y) x is a matrix (15 rows and 1000 columns). I did not specify a column and R crashed - shut down. error signature AppName:rgui.exe AppVer 2.21.51220.0 ModName: r.dll ModVer: 2.21.51220.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug report - cor (PR#8852)
[EMAIL PROTECTED] wrote: > Full_Name: daniel t. O'Shea > Version: 2.2.1 Please read how to report a bug: Please check at least the latest release, which is R-2.3.0! > OS: xp > Submission from: (NULL) (156.98.28.4) > > > using the cor command in the base package. > > cor(x,y) > Please read how to report a bug: Please specify reproducible examples! Under R-2.3.0 the following works for me: set.seed(1) x <- y <- matrix(rnorm(15000), nrow=15) res <- cor(x,y) Uwe Ligges > x is a matrix (15 rows and 1000 columns). I did not specify a column and R > crashed - shut down. > > error signature > AppName:rgui.exe AppVer 2.21.51220.0 > ModName: r.dll > ModVer: 2.21.51220.0 > > __ > 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] @ accesses attributes, not just formal slots ?
Using the '@' operator, I am able to extract a 'names' attribute
assigned to a formal object.
However, I can not use the replacement form ('@<-') to assign that
attribute.
> setClass("foo", representation("numeric"))
[1] "foo"
> (new("foo", 1:4)->a)
An object of class “foo”
[1] 1 2 3 4
> names(a) <- LETTERS[1:4]
> [EMAIL PROTECTED]
[1] "A" "B" "C" "D"
> [EMAIL PROTECTED] <- LETTERS[5:8]
Error in checkSlotAssignment(object, name, value) :
"names" is not a slot in class "foo"
I don't know that this asymmetry will ever cause a problem, but I
just wanted to note it because it appears from the help pages
'slot {methods}' and 'slotOp {base}' that the '@' operator is only
intended to provide access to defined slots.
I am still on R 2.2.1.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 initialize methods, unexpected recursive callNextMethod
John Chambers <[EMAIL PROTECTED]> writes: > It's a bug resulting from the combination of: > 1. multiple recursive levels of callNextMethod() > 2. nonstandard arguments in the method definition; that is, (.Object, > x) vs .Object, ...) for the generic. Thanks for the explanation and work around suggestion. If I'm feeling brave, perhaps I'll take a look at the addNextMethod and callNextMethod computations. We found this bug for a "real" use-case, so I have some interest in a solution that doesn't involve changing the initializers for the three classes involved... Best, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] @ accesses attributes, not just formal slots ?
On Thu, 11 May 2006, Parlamis Franklin wrote:
> Using the '@' operator, I am able to extract a 'names' attribute
> assigned to a formal object.
> However, I can not use the replacement form ('@<-') to assign that
> attribute.
>
> > setClass("foo", representation("numeric"))
> [1] "foo"
> > (new("foo", 1:4)->a)
> An object of class ?foo?
> [1] 1 2 3 4
> > names(a) <- LETTERS[1:4]
> > [EMAIL PROTECTED]
> [1] "A" "B" "C" "D"
> > [EMAIL PROTECTED] <- LETTERS[5:8]
> Error in checkSlotAssignment(object, name, value) :
> "names" is not a slot in class "foo"
>
> I don't know that this asymmetry will ever cause a problem, but I
> just wanted to note it because it appears from the help pages
> 'slot {methods}' and 'slotOp {base}' that the '@' operator is only
> intended to provide access to defined slots.
Yes, it is intended so. It is a side effect of the current implementation
that @ will also access attributes, but that may change. Note that the
help page for @ says
These operators support the formal classes of package 'methods'.
See 'slot' for further details. Currently there is no checking
that the object is an instance of a class.
so this should not come as a surprise to you.
--
Brian D. Ripley, [EMAIL PROTECTED]
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
[Rd] PGI 6.1 compile error
I am trying to compile R-2.3.0 (both first release and patched
2006-05-10) on Red Hat Enterprise Linux AS release 3 (Taroon Update 7)
using the Portland Group compiler version 6.1 and the notes from
Jennifer Lai on p33 of "R Installation and Administration" version 2.3.0
(2006-04-24). I have not used this compiler before, so it is possible
things are messed up more than usual, even for me.
Following the R Installation and Administration notes I set
export PGI=/usr/pgi/linux86-64/6.1
export PATH=$PGI/bin:$PATH
export MANPATH=$MANPATH=$PGI/man:/
export CC=pgcc
export CFLAGS="-g -O2 -Kieee"
export CPPFLAGS="-I$PGI/include -I$PGI/include/CC"
export F77=pgf77
export FFLAGS="-g -O2 -Kieee"
export CXX="pgCC"
export CXXFLAGS="-g -O2 -Kieee"
export F95=pgf95
export FCFLAGS="-g -O2 -Kieee"
export SHLIB_CXXLDFLAGS=-shared
export SHLIB_LDFLAGS=-shared
export LDFLAGS="-L$PGI/libso -L/usr/lib64"
However, the last line causes
:../../src/R-2.3.0-patched/configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
loading site script '../../src/R-2.3.0-patched/config.site'
checking for gcc... pgcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
Either unsetting LDFLAGS, or setting it to "-L/usr/lib64"
.../../src/R-2.3.0-patched/configure --x-libraries=/usr/X11R6/lib64
configures but I get
checking whether C99 double complex is supported...
checking complex.h usability... no
checking complex.h presence... yes
configure: WARNING: complex.h: present but cannot be compiled
configure: WARNING: complex.h: check for missing prerequisite headers?
configure: WARNING: complex.h: see the Autoconf documentation
configure: WARNING: complex.h: section "Present But Cannot Be Compiled"
configure: WARNING: complex.h: proceeding with the preprocessor's result
configure: WARNING: complex.h: in the future, the compiler will take
precedence
configure: WARNING: ## --- ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ## --- ##
checking for complex.h... yes
checking for double complex... no
no
checking for cblas_cdotu_sub in vecLib framework... no
R is now configured for x86_64-unknown-linux-gnu
Source directory: ../../src/R-2.3.0-patched
Installation directory:/usr/local
C compiler:pgcc -g -O2 -Kieee
Fortran 77 compiler: pgf77 -g -O2 -Kieee
C++ compiler: pgCC -g -O2 -Kieee
Fortran 90/95 compiler:pgf95 -g -O2 -Kieee
Interfaces supported: X11, tcltk
External libraries:readline
Additional capabilities: PNG, JPEG, iconv, MBCS, NLS
Options enabled: R profiling
Recommended packages: yes
configure: WARNING: you cannot build info or html versions of the R manuals
However, when I make I get
pgcc -shared -L/usr/lib64 -o tools.so text.o init.o Rmd5.o md5.o
mkdir -p -- ../../../../library/tools/libs
make[5]: Leaving directory
`/home/mfa/gilp/toolchain/R/mfa04559/R-2.3.0PGI/src/library/tools/src'
make[4]: Leaving directory
`/home/mfa/gilp/toolchain/R/mfa04559/R-2.3.0PGI/src/library/tools/src'
**ERROR: in routine alloca() there is a
stack overflow: thread 0, max 10228KB, used 0KB, request 16B
make[3]: *** [all] Error 1
make[3]: Leaving directory
`/home/mfa/gilp/toolchain/R/mfa04559/R-2.3.0PGI/src/library/tools'
make[2]: *** [R] Error 1
make[2]: Leaving directory
`/home/mfa/gilp/toolchain/R/mfa04559/R-2.3.0PGI/src/library'
make[1]: *** [R] Error 1
make[1]: Leaving directory
`/home/mfa/gilp/toolchain/R/mfa04559/R-2.3.0PGI/src'
make: *** [R] Error 1
Any help would be appreciated.
Paul Gilbert
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
