[Rd] Detaching one package can remove the S4 methods of another (PR#14087)
Putting on public record
library(spdep)
showMethods("[")
detach("package:spdep", unload = TRUE)
detach("package:Matrix", unload=TRUE)
showMethods("[") # sp methods still there
detach("package:spam", unload = TRUE)
showMethods("[") # sp methods have gone
This is one of several examples found by package testing in R-devel
(this one from BayesX) with _R_CHECK_UNLOAD_NAMESPACES_ set.
Session info after the first command:
R version 2.10.0 Patched (2009-11-23 r50545)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_GB.utf8 LC_NUMERIC=C
[3] LC_TIME=en_GB.utf8LC_COLLATE=C
[5] LC_MONETARY=C LC_MESSAGES=en_GB.utf8
[7] LC_PAPER=en_GB.utf8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.utf8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] spdep_0.4-52 nlme_3.1-96coda_0.13-4MASS_7.3-4
[5] Matrix_0.999375-32 lattice_0.17-26spam_0.15-5boot_1.2-41
[9] maptools_0.7-26foreign_0.8-38 sp_0.9-47 deldir_0.0-10
loaded via a namespace (and not attached):
[1] grid_2.10.0
Happens also in 2.10.0 and
R version 2.11.0 Under development (unstable) (2009-11-25 r50568)
--
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
[Rd] "bug report" field in DESCRIPTION file?
A lot of R packages are now effectively maintained by several people
and so use sites like R-forge or google code for development. This
means the best way to report bugs or problems with these packages is
via the development site's bug tracking rather than emailing the
maintainer. Could we agree on a field in DESCRIPTION explicitly for
bug reports?
The DESCRIPTION file has an optional URL field which generally sends
the user to the 'home page' of the package. Whether or not there is a
bug tracker somewhere there isn't made explicit, so I don't think
overloading URL for a bug report address is a good idea. The Hmisc
package mentions its bug tracker in the Description field and also has
it in the URL field with three other URLs. This tells me a bug report
field might be a better idea.
I'd prefer an optional field called 'BugReports:', which would be a
URL, and this could either be the http: address of a web site bug
tracker or a mailto: URL (of a real live human or a mail-based
tracker).
If there's agreement on this then a further step may be to write a
'bugreport(package)' function that would first look for a BugReport
field, then the URL or maintainer fields to give the poor confused
user some advice on what to do. Then when someone emails R-dev saying
they think there's a bug in package foo, we can say "Have you read the
output of 'bugreport("foo")'?" which might be more helpful than saying
'bugs with 'foo' should be reported to the maintainer'.
Just an idea for a rainy morning...
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "bug report" field in DESCRIPTION file?
On 26/11/2009 7:09 AM, Barry Rowlingson wrote:
A lot of R packages are now effectively maintained by several people
and so use sites like R-forge or google code for development. This
means the best way to report bugs or problems with these packages is
via the development site's bug tracking rather than emailing the
maintainer. Could we agree on a field in DESCRIPTION explicitly for
bug reports?
The DESCRIPTION file has an optional URL field which generally sends
the user to the 'home page' of the package. Whether or not there is a
bug tracker somewhere there isn't made explicit, so I don't think
overloading URL for a bug report address is a good idea. The Hmisc
package mentions its bug tracker in the Description field and also has
it in the URL field with three other URLs. This tells me a bug report
field might be a better idea.
I'd prefer an optional field called 'BugReports:', which would be a
URL, and this could either be the http: address of a web site bug
tracker or a mailto: URL (of a real live human or a mail-based
tracker).
If there's agreement on this then a further step may be to write a
'bugreport(package)' function that would first look for a BugReport
field, then the URL or maintainer fields to give the poor confused
user some advice on what to do. Then when someone emails R-dev saying
they think there's a bug in package foo, we can say "Have you read the
output of 'bugreport("foo")'?" which might be more helpful than saying
'bugs with 'foo' should be reported to the maintainer'.
This sounds like a good idea, though I would add a "package" parameter
to the bug.report() function, rather than creating a new function.
Does the logic below sound right for bug.report() with the package
specified?
If there's a BugReports field, bug.report() calls browseURL() on that page.
If not, it does more or less what it does now, but
- it defaults "address" to the package maintainer.
- it adds a line in the intro to the message pointing to the URL field
if there was one.
Duncan Murdoch
Just an idea for a rainy morning...
Barry
__
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
Re: [Rd] "bug report" field in DESCRIPTION file?
> "DM" == Duncan Murdoch
> on Thu, 26 Nov 2009 08:39:27 -0500 writes:
DM> On 26/11/2009 7:09 AM, Barry Rowlingson wrote:
>> A lot of R packages are now effectively maintained by several people
>> and so use sites like R-forge or google code for development. This
>> means the best way to report bugs or problems with these packages is
>> via the development site's bug tracking rather than emailing the
>> maintainer. Could we agree on a field in DESCRIPTION explicitly for
>> bug reports?
>>
>> The DESCRIPTION file has an optional URL field which generally sends
>> the user to the 'home page' of the package. Whether or not there is a
>> bug tracker somewhere there isn't made explicit, so I don't think
>> overloading URL for a bug report address is a good idea. The Hmisc
>> package mentions its bug tracker in the Description field and also has
>> it in the URL field with three other URLs. This tells me a bug report
>> field might be a better idea.
>>
>> I'd prefer an optional field called 'BugReports:', which would be a
>> URL, and this could either be the http: address of a web site bug
>> tracker or a mailto: URL (of a real live human or a mail-based
>> tracker).
>>
>> If there's agreement on this then a further step may be to write a
>> 'bugreport(package)' function that would first look for a BugReport
>> field, then the URL or maintainer fields to give the poor confused
>> user some advice on what to do. Then when someone emails R-dev saying
>> they think there's a bug in package foo, we can say "Have you read the
>> output of 'bugreport("foo")'?" which might be more helpful than saying
>> 'bugs with 'foo' should be reported to the maintainer'.
>>
DM> This sounds like a good idea, though I would add a "package" parameter
DM> to the bug.report() function, rather than creating a new function.
I agree (good idea; use bug.report() with arguments).
DM> Does the logic below sound right for bug.report() with the package
DM> specified?
DM> If there's a BugReports field, bug.report() calls browseURL() on that
page.
I'm not sure if that's easy: One main reason for bug.report() is
to auto-collect the necessary info and put it into the body of
an e-mail message. So, I think the above only "works" when the
BugReports fields is a 'mailto:' URL, but not, e.g., when it
points to an R-forge bug tracking web page form.
DM> If not, it does more or less what it does now, but
DM> - it defaults "address" to the package maintainer.
DM> - it adds a line in the intro to the message pointing to the URL field
DM> if there was one.
that sounds good.
Martin
DM> Duncan Murdoch
>> Just an idea for a rainy morning...
>>
>> Barry
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
DM> __
DM> R-devel@r-project.org mailing list
DM> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "bug report" field in DESCRIPTION file?
On 26/11/2009 9:20 AM, Martin Maechler wrote:
> "DM" == Duncan Murdoch
> on Thu, 26 Nov 2009 08:39:27 -0500 writes:
DM> On 26/11/2009 7:09 AM, Barry Rowlingson wrote:
>> A lot of R packages are now effectively maintained by several people
>> and so use sites like R-forge or google code for development. This
>> means the best way to report bugs or problems with these packages is
>> via the development site's bug tracking rather than emailing the
>> maintainer. Could we agree on a field in DESCRIPTION explicitly for
>> bug reports?
>>
>> The DESCRIPTION file has an optional URL field which generally sends
>> the user to the 'home page' of the package. Whether or not there is a
>> bug tracker somewhere there isn't made explicit, so I don't think
>> overloading URL for a bug report address is a good idea. The Hmisc
>> package mentions its bug tracker in the Description field and also has
>> it in the URL field with three other URLs. This tells me a bug report
>> field might be a better idea.
>>
>> I'd prefer an optional field called 'BugReports:', which would be a
>> URL, and this could either be the http: address of a web site bug
>> tracker or a mailto: URL (of a real live human or a mail-based
>> tracker).
>>
>> If there's agreement on this then a further step may be to write a
>> 'bugreport(package)' function that would first look for a BugReport
>> field, then the URL or maintainer fields to give the poor confused
>> user some advice on what to do. Then when someone emails R-dev saying
>> they think there's a bug in package foo, we can say "Have you read the
>> output of 'bugreport("foo")'?" which might be more helpful than saying
>> 'bugs with 'foo' should be reported to the maintainer'.
>>
DM> This sounds like a good idea, though I would add a "package" parameter
DM> to the bug.report() function, rather than creating a new function.
I agree (good idea; use bug.report() with arguments).
DM> Does the logic below sound right for bug.report() with the package
DM> specified?
DM> If there's a BugReports field, bug.report() calls browseURL() on that
page.
I'm not sure if that's easy: One main reason for bug.report() is
to auto-collect the necessary info and put it into the body of
an e-mail message. So, I think the above only "works" when the
BugReports fields is a 'mailto:' URL, but not, e.g., when it
points to an R-forge bug tracking web page form.
The idea was that we would not use the auto-collection at all if there
was a BugReports field, because the package author(s) had indicated by
it that they didn't want emailed bug reports.
Duncan Murdoch
DM> If not, it does more or less what it does now, but
DM> - it defaults "address" to the package maintainer.
DM> - it adds a line in the intro to the message pointing to the URL field
DM> if there was one.
that sounds good.
Martin
DM> Duncan Murdoch
>> Just an idea for a rainy morning...
>>
>> Barry
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
DM> __
DM> R-devel@r-project.org mailing list
DM> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "bug report" field in DESCRIPTION file?
On Thu, Nov 26, 2009 at 1:39 PM, Duncan Murdoch wrote:
> This sounds like a good idea, though I would add a "package" parameter to
> the bug.report() function, rather than creating a new function.
I'm sure when I did help.search("bug") and help.search("report") this
morning I didn't see this function! Otherwise I would have suggested
that. bug.report(package="bazbrain"). Oh dear, no maintainer.
> Does the logic below sound right for bug.report() with the package
> specified?
>
> If there's a BugReports field, bug.report() calls browseURL() on that page.
>
> If not, it does more or less what it does now, but
> - it defaults "address" to the package maintainer. - it adds a line in the
> intro to the message pointing to the URL field if there was one.
Martin Maechler's reservation about not being able to fill in the R
details for bug reports on trackers isn't too much of a problem, since
the bug tracker form could have fields for R version, session info
etc, or at least a big warning saying "Please include the following
info" (inside a tag).
So how about if bug.report(package="foo") has a BugReports: field,
you print out 'The following information may be useful to your bug
report' and dump the relevant things ready for cut n paste into a bug
tracker, then browseURL().
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] p-generalized normal distribution
There is a CRAN Task View for probability Distributions. take a look there! Kjetil On Tue, Nov 24, 2009 at 1:53 PM, Steve Kalke wrote: > Hello, > > I would like to know if there is an R-package available for computing the > density, distribution function, quantiles and random numbers of the > p-generalized normal distribution or if somebody is already working on it. > > Best regards, > Steve Kalke > > __ > 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
Re: [Rd] p-generalized normal distribution
He already asked... And I don t know any pkg implementing this distribution... iPhone.fan Le 26 nov. 2009 à 21:22, Kjetil Halvorsen m> a écrit : There is a CRAN Task View for probability Distributions. take a look there! Kjetil On Tue, Nov 24, 2009 at 1:53 PM, Steve Kalke > wrote: Hello, I would like to know if there is an R-package available for computing the density, distribution function, quantiles and random numbers of the p-generalized normal distribution or if somebody is already working on it. Best regards, Steve Kalke __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] compiling on snow leopard: Cocoa errors?!?!?!
Dear R-gurus, I'm trying to compile R on my new mac. It's snow leopard. So far I've seemed to be doing pretty well. I've looked at http://cran.r-project.org/bin/macosx/tools/ http://r.research.att.com/exp/ http://r.research.att.com/building.html http://r.research.att.com/tools/ All of which have been very helpful. Looking at the threads I've got around some X11 issues that stopped the configure script working but now when I excute make I get the error below. Any ideas? Thanks in advance, Paul R is now configured for i386-apple-darwin10.2.0 Source directory: . Installation directory:/Library/Frameworks C compiler:gcc -arch x86_64 -std=gnu99 -g -O2 Fortran 77 compiler: gfortran -arch x86_64 -g -O2 C++ compiler: g++ -arch x86_64 -g -O2 Fortran 90/95 compiler:gfortran -arch x86_64 -g -O2 Obj-C compiler:gcc -arch x86_64 -g -O2 Interfaces supported: X11, aqua, tcltk External libraries:readline, BLAS(vecLib), LAPACK(in blas), ICU Additional capabilities: NLS Options enabled: framework, R profiling, Java Recommended packages: yes sh-3.2# echo "./configure SHELL='/bin/bash' r_arch=x86_64 CC="gcc -arch x86_64 -std=gnu99" CXX="g++ -arch x86_64" OBJC="gcc -arch x86_64" F77="gfortran -arch x86_64" FC="gfortran -arch x86_64" --with-system-zlib --with-blas='-framework vecLib' --with-lapack --x-includes='-I/usr/X11/include/X11' --x-libraries='-L/usr/X11/lib' X_LIBS=-L/usr/X11/lib" > ~/R/compileR.txt sh-3.2# make make[1]: Nothing to be done for `R'. make[1]: Nothing to be done for `R'. make[2]: Nothing to be done for `R'. . . etc building package 'tools' all.R is unchanged make[6]: `Makedeps' is up to date. ../../../../library/tools/libs/x86_64/tools.so is unchanged building package 'utils' all.R is unchanged make[4]: Nothing to be done for `iconvlist'. building package 'grDevices' all.R is unchanged ../../../library/grDevices/R/grDevices is unchanged gcc -arch x86_64 -I../../../../include -I../../../../include/x86_64 -I../../../include -I../../../../src/include -DHAVE_CONFIG_H -I/usr/local/include -fPIC -g -O2 -c qdCocoa.m -o qdCocoa.o In file included from /System/Library/Frameworks/Foundation.framework/Headers/NSCharacterSet.h:8, from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:15, from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12, from qdCocoa.h:39, from qdCocoa.m:24: /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:278: error: format string argument follows the args to be formatted /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:280: error: format string argument follows the args to be formatted In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:25, from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12, from qdCocoa.h:39, from qdCocoa.m:24: /System/Library/Frameworks/Foundation.framework/Headers/NSException.h:62: error: format string argument follows the args to be formatted qdCocoa.m: In function '+[QuartzCocoaView quartzWindowWithRect:andInfo:]': qdCocoa.m:90: warning: class 'QuartzCocoaView' does not implement the 'NSWindowDelegate' protocol make[5]: *** [qdCocoa.o] Error 1 make[4]: *** [mksrc] Error 1 make[3]: *** [all] Error 2 make[2]: *** [R] Error 1 make[1]: *** [R] Error 1 make: *** [R] Error 1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compiling on snow leopard: Cocoa errors?!?!?!
Paul, at a first glance that seems like an issue in your system to me since the errors come from system headers and not from our code. Which compilers are you using and which Xcode version? Cheers, Simon On Nov 26, 2009, at 1:16 PM, Homer Paul Benton wrote: Dear R-gurus, I'm trying to compile R on my new mac. It's snow leopard. So far I've seemed to be doing pretty well. I've looked at http://cran.r-project.org/bin/macosx/tools/ http://r.research.att.com/exp/ http://r.research.att.com/building.html http://r.research.att.com/tools/ All of which have been very helpful. Looking at the threads I've got around some X11 issues that stopped the configure script working but now when I excute make I get the error below. Any ideas? Thanks in advance, Paul R is now configured for i386-apple-darwin10.2.0 Source directory: . Installation directory:/Library/Frameworks C compiler:gcc -arch x86_64 -std=gnu99 -g -O2 Fortran 77 compiler: gfortran -arch x86_64 -g -O2 C++ compiler: g++ -arch x86_64 -g -O2 Fortran 90/95 compiler:gfortran -arch x86_64 -g -O2 Obj-C compiler: gcc -arch x86_64 -g -O2 Interfaces supported: X11, aqua, tcltk External libraries:readline, BLAS(vecLib), LAPACK(in blas), ICU Additional capabilities: NLS Options enabled: framework, R profiling, Java Recommended packages: yes sh-3.2# echo "./configure SHELL='/bin/bash' r_arch=x86_64 CC="gcc - arch x86_64 -std=gnu99" CXX="g++ -arch x86_64" OBJC="gcc -arch x86_64" F77="gfortran -arch x86_64" FC="gfortran -arch x86_64" -- with-system-zlib --with-blas='-framework vecLib' --with-lapack --x- includes='-I/usr/X11/include/X11' --x-libraries='-L/usr/X11/lib' X_LIBS=-L/usr/X11/lib" > ~/R/compileR.txt sh-3.2# make make[1]: Nothing to be done for `R'. make[1]: Nothing to be done for `R'. make[2]: Nothing to be done for `R'. . . etc building package 'tools' all.R is unchanged make[6]: `Makedeps' is up to date. ../../../../library/tools/libs/x86_64/tools.so is unchanged building package 'utils' all.R is unchanged make[4]: Nothing to be done for `iconvlist'. building package 'grDevices' all.R is unchanged ../../../library/grDevices/R/grDevices is unchanged gcc -arch x86_64 -I../../../../include -I../../../../include/x86_64 - I../../../include -I../../../../src/include -DHAVE_CONFIG_H -I/usr/ local/include -fPIC -g -O2 -c qdCocoa.m -o qdCocoa.o In file included from /System/Library/Frameworks/ Foundation.framework/Headers/NSCharacterSet.h:8, from /System/Library/Frameworks/Foundation.framework/ Headers/Foundation.h:15, from /System/Library/Frameworks/Cocoa.framework/ Headers/Cocoa.h:12, from qdCocoa.h:39, from qdCocoa.m:24: /System/Library/Frameworks/Foundation.framework/Headers/NSString.h: 278: error: format string argument follows the args to be formatted /System/Library/Frameworks/Foundation.framework/Headers/NSString.h: 280: error: format string argument follows the args to be formatted In file included from /System/Library/Frameworks/ Foundation.framework/Headers/Foundation.h:25, from /System/Library/Frameworks/Cocoa.framework/ Headers/Cocoa.h:12, from qdCocoa.h:39, from qdCocoa.m:24: /System/Library/Frameworks/Foundation.framework/Headers/ NSException.h:62: error: format string argument follows the args to be formatted qdCocoa.m: In function '+[QuartzCocoaView quartzWindowWithRect:andInfo:]': qdCocoa.m:90: warning: class 'QuartzCocoaView' does not implement the 'NSWindowDelegate' protocol make[5]: *** [qdCocoa.o] Error 1 make[4]: *** [mksrc] Error 1 make[3]: *** [all] Error 2 make[2]: *** [R] Error 1 make[1]: *** [R] Error 1 make: *** [R] Error 1 __ 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
Re: [Rd] compiling on snow leopard: Cocoa errors?!?!?!
Paul, On Nov 26, 2009, at 9:03 PM, Homer Paul Benton wrote: > I'm currently using > > gcc --version > i686-apple-darwin8-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5564) That is the wrong compiler - it's a Leopard compiler (Xcode 3.1/3.1.1 to be precise - see that it says darwin8 which is even 10.4 = Tiger!). Your Xcode seems to be seriously messed up -- I'd strongly recommend re-installing all Xcode 3.2 (run sudo gfortran-uninstall before you start) and Fortran (either the CRAN version or the Snow Leopard(!!) version from Tools). > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > sh-3.2# gfortran --version > GNU Fortran (GCC) 4.2.1 (Apple Inc. build 5564) > Copyright (C) 2007 Free Software Foundation, Inc. > > GNU Fortran comes with NO WARRANTY, to the extent permitted by law. > You may redistribute copies of GNU Fortran > under the terms of the GNU General Public License. > For more information about these matters, see the file named COPYING > > > and xcode 3.2 (1610) > > At the risk of sounding stupid, I compiled the netCDF library and the > compiliers seemed happy for that. ?!?! > NetCDF doesn't use anything from the system so even wrong compilers won't throw it off. Cheers, Simon > Cheers, > > Paul > > I downloaded and 'installed' the > > On 27 Nov 2009, at 00:54, Simon Urbanek wrote: > >> Paul, >> >> at a first glance that seems like an issue in your system to me since >> the errors come from system headers and not from our code. Which >> compilers are you using and which Xcode version? >> >> Cheers, >> Simon >> >> >> On Nov 26, 2009, at 1:16 PM, Homer Paul Benton wrote: >> >>> Dear R-gurus, >>> >>> I'm trying to compile R on my new mac. It's snow leopard. So far >>> I've seemed to be doing pretty well. I've looked at >>> >>> http://cran.r-project.org/bin/macosx/tools/ >>> >>> http://r.research.att.com/exp/ >>> >>> http://r.research.att.com/building.html >>> >>> http://r.research.att.com/tools/ >>> >>> All of which have been very helpful. Looking at the threads I've got >>> around some X11 issues that stopped the configure script working but >>> now when I excute make I get the error below. Any ideas? >>> >>> Thanks in advance, >>> >>> Paul >>> >>> R is now configured for i386-apple-darwin10.2.0 >>> >>> Source directory: . >>> Installation directory:/Library/Frameworks >>> >>> C compiler:gcc -arch x86_64 -std=gnu99 -g -O2 >>> Fortran 77 compiler: gfortran -arch x86_64 -g -O2 >>> >>> C++ compiler: g++ -arch x86_64 -g -O2 >>> Fortran 90/95 compiler:gfortran -arch x86_64 -g -O2 >>> Obj-C compiler: gcc -arch x86_64 -g -O2 >>> >>> Interfaces supported: X11, aqua, tcltk >>> External libraries:readline, BLAS(vecLib), LAPACK(in blas), >>> ICU >>> Additional capabilities: NLS >>> Options enabled: framework, R profiling, Java >>> >>> Recommended packages: yes >>> >>> sh-3.2# echo "./configure SHELL='/bin/bash' r_arch=x86_64 CC="gcc - >>> arch x86_64 -std=gnu99" CXX="g++ -arch x86_64" OBJC="gcc -arch >>> x86_64" F77="gfortran -arch x86_64" FC="gfortran -arch x86_64" -- >>> with-system-zlib --with-blas='-framework vecLib' --with-lapack --x- >>> includes='-I/usr/X11/include/X11' --x-libraries='-L/usr/X11/lib' >>> X_LIBS=-L/usr/X11/lib" > ~/R/compileR.txt >>> >>> >>> sh-3.2# make >>> make[1]: Nothing to be done for `R'. >>> make[1]: Nothing to be done for `R'. >>> make[2]: Nothing to be done for `R'. >>> . >>> . etc >>> building package 'tools' >>> all.R is unchanged >>> make[6]: `Makedeps' is up to date. >>> ../../../../library/tools/libs/x86_64/tools.so is unchanged >>> building package 'utils' >>> all.R is unchanged >>> make[4]: Nothing to be done for `iconvlist'. >>> building package 'grDevices' >>> all.R is unchanged >>> ../../../library/grDevices/R/grDevices is unchanged >>> gcc -arch x86_64 -I../../../../include -I../../../../include/x86_64 - >>> I../../../include -I../../../../src/include -DHAVE_CONFIG_H -I/usr/ >>> local/include -fPIC -g -O2 -c qdCocoa.m -o qdCocoa.o >>> In file included from /System/Library/Frameworks/ >>> Foundation.framework/Headers/NSCharacterSet.h:8, >>> from /System/Library/Frameworks/Foundation.framework/ >>> Headers/Foundation.h:15, >>> from /System/Library/Frameworks/Cocoa.framework/ >>> Headers/Cocoa.h:12, >>> from qdCocoa.h:39, >>> from qdCocoa.m:24: >>> /System/Library/Frameworks/Foundation.framework/Headers/NSString.h: >>> 278: error: format string argument follows the args to be formatted >>> /System/Library/Frameworks/Foundation.framework/Headers/NSString.h: >>> 280: error: format string argument follows the args to be formatted >>> In file included from /System/Library/Frameworks/ >>> Foun
