Re: [R-SIG-Mac] R 2.6.1 as 64bit under MacOSX
On Nov 25, 2010, at 8:20 AM, Christoph Rathfelder wrote: Hi all, I am currently trying to run a Java-application using R functionality. Caused by the Java-application, I have to use R.2.6.1 Calling the Rlib results in an Exception which includes a hint on wrong architecture of wrapper I tried to rebuild R as 64bit locally, but still after fixing some make files to run the compiling Even old R should compile for 64-bit out of the box -- if you set the flags correctly. The 64-bit support for OS X is there ever since Tiger. Can you supply details? (i.e. how did you try to compile, what did not work etc) , R does not works completely. e.g. installing the rJava Package does not work. Is there also a SnowLeopard Release of this older version somewhere available? I'm not aware of any because such an old R predates SL ... Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] R Nehalem
On Nov 23, 2010, at 11:12 PM, BERND LAMBERTS wrote: Hello i was wondering , did anybody ever resolve the problem with Nehalem Mac Pro's and veclib ? Well, it's not our to resolve - the problem is with Apple. is there maybe somewhere a compiled version which does avoid the problem with veclib ? Sure, CRAN R comes with shared BLAS so you can simply switch to ATLAS or R BLAS (see R-admin for general directions and this list for specific binaries). Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] BLAS benchmarks on R 2.12.0
On Nov 3, 2010, at 12:07 AM, Michael Spiegel wrote: I would like to apologize for cross-posting this message. But I realized that one of my questions may be more appropriate for the SIG-Mac mailing list rather than the R-devel mailing list. You may wish to ignore the other parts of the email. My question is the following: I can't seem to reproduce the speed of the 2.11.1 reference BLAS library. What compiler, which version of the compiler, and what flags are used when an [OS X] R binary is distributed? My test machine is a Mac Pro, so 32-bit x86 architecture. The current build flags for i386 are listed in https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R-build/conf.leopard-i386 They did not change recently so they were the same for 2.11.1. The compiler used is gcc-4.2 from Xcode 3.1.4 (R is built on OS X 10.5.8) with the corresponding Fortran form the tools page. More below. -- Forwarded message -- From: Michael Spiegel michael.m.spie...@gmail.com Date: Sun, Oct 31, 2010 at 12:41 PM Subject: BLAS benchmarks on R 2.12.0 To: r-de...@stat.math.ethz.ch Cc: OpenMx Developers openmx-develop...@list.mail.virginia.edu Hi, I saw on the mailing list and in the NEWS file that some unsafe math transformations were disabled for the reference BLAS implementation that is used in R. We have a set of performance tests for the OpenMx library, and some of the tests have a x3-10 slowdown in R 2.12.0 versus 2.11.1. When I copy the shared library libRblas.0.dylib from the 2.11.1 installation into the 2.12.0 installation, the slowdown goes away. It seems reasonable that BLAS should conform to IEEE requirements. For the purposes of our library, we are considering two options but I need some advice on both choices: 1) Compile the reference BLAS implementation with unsafe optimizations and include it as a part of the OpenMx library. I can't seem to reproduce the speed of the 2.11.1 reference BLAS library. What compiler, which version of the compiler, and what flags are used when an R binary is distributed? My test machine is a Mac Pro, that may change the answer. 2) Is there any support for adding a libRblas.unsafe.dylib shared library in the R installation, much like libRblas.veclib.dylib is currently included in OS X binaries? Then we could just change the OpenMx shared library to use the unsafe library when we give it to users. We currently change the OpenMx shared library to use the reference blas implementation, because it is faster than the veclib implementation for small matrices. Although it would be possible technically, it would mean to include Rblas built by a different version of R which doesn't sound right (the flags are set by configure so there is no easy way to reproduce it in the current R without manual intervention). However, I'm considering adding some alternatives (such as ATLAS for example) in the build and a tool to change the BLAS used - possibly as a separate package. To get back to your problem - did you try the single threaded ATLAS for your problem? The optimizations are not necessarily just for large matrices - in fact ATLAS has several paths depending on the size of the problem. (I'm traveling at the moment so can't run any tests) However, as John pointed out it is pretty much impossible to get a general solution because any benchmarks are very limited to a certain problem and size yet the mechanisms involved are far more complex (and as I was pointing out for the recently discussed speed patches - seeming clear optimization to increase speed can in reality be slower that the untouched code depending on compilers, flags and architecture). Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] BLAS benchmarks on R 2.12.0
On Nov 3, 2010, at 4:49 PM, Michael Spiegel wrote: Thank you, I can run off and do some more tests with this information. I think the culprit on my development machine is that Xcode needs to be upgraded and then I can use -mtune=core2. That alone could explain you performance issue since you gcc is apparently way too old - possibly nothing to do with flags but just gcc capabilities. I have one small follow-up question. I thought the compilation flags for building src/extra/blas had changed from version 2.12.0 to 2.11.1. But you suggest maybe they haven't changed? I did not change anything as far as the configure flags go. Cheers, Simon On Wed, Nov 3, 2010 at 6:31 AM, Simon Urbanek simon.urba...@r-project.org wrote: The current build flags for i386 are listed in https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R-build/conf.leopard-i386 They did not change recently so they were the same for 2.11.1. The compiler used is gcc-4.2 from Xcode 3.1.4 (R is built on OS X 10.5.8) with the corresponding Fortran form the tools page. To get back to your problem - did you try the single threaded ATLAS for your problem? I did try ATLAS and did not see performance improvements. But that attempt was without -mtune=core2. ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] R file indexing under Spotlight
On Oct 27, 2010, at 12:57 PM, Vincent Philion wrote: Hi! a few years back, I posted about a R spotlight importer: https://stat.ethz.ch/pipermail/r-sig-mac/2007-February/003676.html I see no mention of Spotlight in http://cran.r-project.org/bin/macosx/NEWS, so unless I'm mistaken, this isn't installed by default with a new R install on Mac. Any chance to see this included? It's not part of R (neither R.framework nor R.app) - so why should it be included with R? There are many useful plugins for R but there is no reason why they should be included with R itself. Even R packages are not installed by default with R and they bear much closer relationship Finally, none of us wrote it and since it is from 2007 it doesn't seem to have a maintainer Cheers, Simon Vincent Philion, agr., M.Sc. Phytopathologiste Laboratoire de production fruitière intégrée Institut de recherche et de développement en agroenvironnement 335, Rang des vingt-cinq Est Case postale 24 Saint-Bruno-de-Montarville (Québec) J3V 4P8 Tél. bureau: 450 653-7368 poste 224 Tél. laboratoire: 450 653-7368 poste 229 Cellulaire: 514-623-8275 Télécopie: 450 653-1927 Verger du parc national du Mont-Saint-Bruno 330, Rang des vingt-cinq Est Case postale 24 Saint-Bruno-de-Montarville (Québec) J3V 4P8 Téléphone et télécopieur : 450 653-8375 Courriel: vincent.phil...@irda.qc.camailto:vincent.phil...@irda.qc.ca Site Internet: www.irda.qc.cahttp://www.irda.qc.ca Avez-vous réellement besoin d'imprimer ce courriel? Si oui, imprimez-le recto-verso! AVIS DE CONFIDENTIALITÉ Ce message peut contenir de l'information de nature privilégiée et confidentielle. Si vous n'êtes pas le destinataire visé ou croyez l'avoir reçu par erreur, nous vous saurions gré d'en aviser l'émetteur. Si ce message vous a été transmis par erreur, veuillez le détruire sans en communiquer le contenu à d'autres personnes ou le reproduire. [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Rgui freezing on function lookup
On Oct 27, 2010, at 3:14 PM, Elizabeth Purdom wrote: Hello, Lately on my mac OS X (snowleopard) computer, when I run the Rgui it is freezing because of its function lookup feature. Specifically, as I type at the command line, there is a feature where if I type print( it shows at the bottom the arguments for the print function. The problem is when I type a typo (my frequent typo is heaD() it goes to look this up and completely freezes my Rgui and I have to force quit the program. Of course the feature does it as I type, so it doesn't matter if I press the backspace to fix it, etc. It's too late. I don't remember it doing this before, but now it happens many times a day -- I don't know what has changed. It also doesn't do it all the time; I think it is related to having set options(error=recover). This is because it is producing an error that it can't find heaD as a function. I doubt it -- partly because I cannot reproduce it and partly because it uses try(..., silent=TRUE) so that the error setting doesn't matter. Please send me the crash report when it happens so we can have a closer look. Also please try the latest version of R. Also FWIW I see multicore in your list of packages - you cannot use multicore from the GUI (see ?multicore). Thanks, Simon Is there a way to turn off this feature? Failing that, some work around? Its not responding to escape/ctrl-c etc. Thanks, Elizabeth Purdom #this is my session info, though clearly not from when I actually had the error, because R completely crashes and I can not regain control of the program sessionInfo() R version 2.11.1 (2010-05-31) x86_64-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] multicore_0.1-3Rsamtools_1.0.8Biostrings_2.16.9 GenomicFeatures_1.0.10 GenomicRanges_1.0.9IRanges_1.6.17 [7] XML_3.1-1 loaded via a namespace (and not attached): [1] Biobase_2.8.0 biomaRt_2.4.0 BSgenome_1.16.5 DBI_0.2-5 RCurl_1.4-2 RSQLite_0.9-2 rtracklayer_1.8.1 ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How to determine if a Mac is Nehalem-based
On Oct 22, 2010, at 9:58 AM, Steve Lianoglou wrote: Hi, Although I should, I don't follow too closely in the places I should (I don't know where those places are) to know if Apple is aware of this vecLib breakdown issue ... are they? Where can we go to add our voices/votes for them to fix it? The way to go is to file a concise bug report (simply using let's say DGEMM timings) - but I did not have time to do so. If someone else wants to go ahead, let me know and I can pass on the bug # to our contacts at Apple. Apple still has their apple.com/science section, so I guess this should be (somehow) important to them ... maybe we can make an R-SIG-Mac 20-person-strong tidal wave to help force their hand? ;-) Good question - and it's not only R people that are appalled. Cheers, Simon On Thu, Oct 21, 2010 at 12:36 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Oct 21, 2010, at 7:47 AM, Stefan Evert wrote: On 21 Oct 2010, at 03:28, Simon Urbanek wrote: It's not vague at all, it's MacPro4,1 and MacPro5,1 models (you can use use sysctl hw.model to find out what you have). If in doubt, check on Wikipedia ;) The latter uses the Nehalem architecture but I don't have a specimen of those so I can't confirm that the bug still holds true for those. Not just those ... I'm plagued by the same problem on my Penryn-based MacBookPro4,1. In 64-bit mode, BLAS performance breaks down to single core levels, whereas in 32-bit mode (i.e. R --arch=i386) it uses both cores. I posted some benchmark results to this list a few weeks ago. Well, given that it is only a two-thread CPU there is not much you can gain so I wouldn't lose my sleep over it. If you have 16-theads CPU it's a while different story ;). For illustration, those are the timings from your benchmarks (only those that use BLAS) for 64-bit R 2.1...@10.6.4 on a 2.66GHz MacPro4,1: testR BLAS vecLib ATLAS MKL inner M %*% t(M) D 19.961 3.470 0.519 0.662 inner tcrossprod D 0.658 1.867 0.243 0.235 inner crossprod t(M) D 9.574 1.849 0.242 0.256 cosine normalised D 0.798 2.009 0.385 0.411 cosine general D0.770 1.993 0.380 0.352 euclid() D 2.072 3.271 1.637 1.635 euclid() small D0.515 0.821 0.421 0.395 As you can see both MKL and ATLAS outperform vecLib and R BLAS by an order of magnitude. It's sad, because vecLib used to be fairly well optimized ... (in fact it is actually some version of ATLAS which is even more strange ...). My solution has also been to switch to the reference BLAS, which outperforms vecLib on most of the operations I benchmarked, except for crossprod(), which is terribly slow (more than 10x slower than tcrossprod()). I've just tested again with R 2.12.0, and the situation has become even worse: now an explicit matrix multiplication M %*% t(M) -- which used to be fast -- performs as poorly as crossprod(). Any ideas about this? The crossprod() slowdown isn't a Mac problem: I got similar results on a Pentium Dual Core laptop running Ubuntu. If this is a known problem of the reference BLAS, is there any way to work around it? Apart from the speed hiccups, in my benchmarks vecLib BLAS performed consistently slower than the reference BLAS. Is there evidence from other benchmarks / hardware architectures that vecLib can be faster? If not, perhaps the default should be _not_ to use vecLib on Mac? Or perhaps it would be possible to autodetect hardware in the R startup wrapper and select the BLAS that's known to run faster on this setup? I don't think we would want to do that since that would prevent the user from choosing the BLAS they want to use. We will probably abandon vecLib as the default for the next release (more due to its numerical instability issues) and maybe provide all three options (vecLib, R BLAS, ATLAS) for the user to choose from in case they have a machine that can take advantage of it. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- Steve Lianoglou Graduate Student: Computational Systems Biology | Memorial Sloan-Kettering Cancer Center | Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] [R-sig-ME] lme4 missing from repositories?
On Oct 21, 2010, at 9:47 AM, Federico Calboli wrote:
Mark,
To the extent that it may be helpful here and I can do more if need be, I
built 32 bit R 2.12.0 patched on Snow Leopard (10.6.4), using the R BLAS
rather than Apple's veclib. This is on an early 2009 17 MBP with a 2.93 Ghz
Core 2 Duo (MacBookPro5,2) and 4Gb of RAM.
Based upon Doug's comment in this thread that the issue may be related to
the use of Apple's veclib BLAS, as opposed to R's reference BLAS, I ran some
tests.
My config includes:
--without-blas --without-lapack
just to be sure that the above is the correct invocation, based upon what I
found online.
Using this build, with all CRAN packages freshly installed using this build,
I ran the example used here with lme4 0.999375-35. I get:
library(lme4)
y - (1:20)*pi; x - (1:20)^2;group - gl(2,10)
M2. - lmer (y ~ 1 + x + (1 + x | group))
M2 - lmer (y ~ x + ( x | group))
identical(fixef(M2), fixef(M2.))
[1] TRUE
I then created a function so that I could use replicate() to run this test a
larger number of times:
testlme4 - function()
{
y - (1:20)*pi; x - (1:20)^2;group - gl(2,10)
M2. - lmer (y ~ 1 + x + (1 + x | group))
M2 - lmer (y ~ x + ( x | group))
identical(fixef(M2), fixef(M2.))
}
RES - replicate(1000, testlme4())
all(RES)
[1] TRUE
table(RES)
RES
TRUE
1000
Does the example need to be run a very large number of times to be sure
that it does not fail, or is the above a reasonable indication that the use
of R's BLAS is a more appropriate default option for R on OSX? If I am not
mistaken (and somebody correct me if wrong), R's BLAS is the default on
Windows and Linux (from my recollections on Fedora). Why should OSX be
different in that regard?
Thanks for the very informative post. I added R-Mac in my reply to see if
someone can come up with a response to your query. It would also be
interesting to know if it were possible to switch the OSX R binary to use the
R BLAS library.
Yes, see R for Mac FAQ 12.5.
Cheers,
Simon
Also, as an aside to Federico, I use 32 bit R on OSX largely because I have
to interact with an Oracle server via RODBC. The only ODBC drivers available
for Oracle on OSX are 32 bit and they are not compatible with 64 bit R. It
would be rather cumbersome when running reports (via Sweave) to first
extract the data in 32 bit R and then switch to 64 bit R to run the reports.
I can run it all in a single step using 32 bit R. I also do not have a need
for the larger memory address space afforded by 64 bit R.
I'm very primitive in any integration between R and anything else, so much so
that I abandoned Emacs (well integrated with R) for Vim (not as well
integrated). On the other hand I do need the greater memory address space of
R64. I understand my needs and habits are not universally shared, but, if the
*only* reason for using R32 vs R64 is the 20% speed difference, I'd use R64
for running lme4.
Best,
Federico
--
Federico C. F. Calboli
Department of Epidemiology and Biostatistics
Imperial College, St. Mary's Campus
Norfolk Place, London W2 1PG
Tel +44 (0)20 75941602 Fax +44 (0)20 75943193
f.calboli [.a.t] imperial.ac.uk
f.calboli [.a.t] gmail.com
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How to determine if a Mac is Nehalem-based
On Oct 21, 2010, at 7:47 AM, Stefan Evert wrote: On 21 Oct 2010, at 03:28, Simon Urbanek wrote: It's not vague at all, it's MacPro4,1 and MacPro5,1 models (you can use use sysctl hw.model to find out what you have). If in doubt, check on Wikipedia ;) The latter uses the Nehalem architecture but I don't have a specimen of those so I can't confirm that the bug still holds true for those. Not just those ... I'm plagued by the same problem on my Penryn-based MacBookPro4,1. In 64-bit mode, BLAS performance breaks down to single core levels, whereas in 32-bit mode (i.e. R --arch=i386) it uses both cores. I posted some benchmark results to this list a few weeks ago. Well, given that it is only a two-thread CPU there is not much you can gain so I wouldn't lose my sleep over it. If you have 16-theads CPU it's a while different story ;). For illustration, those are the timings from your benchmarks (only those that use BLAS) for 64-bit R 2.1...@10.6.4 on a 2.66GHz MacPro4,1: testR BLAS vecLib ATLAS MKL inner M %*% t(M) D 19.961 3.470 0.519 0.662 inner tcrossprod D 0.658 1.867 0.243 0.235 inner crossprod t(M) D 9.574 1.849 0.242 0.256 cosine normalised D 0.798 2.009 0.385 0.411 cosine general D0.770 1.993 0.380 0.352 euclid() D 2.072 3.271 1.637 1.635 euclid() small D0.515 0.821 0.421 0.395 As you can see both MKL and ATLAS outperform vecLib and R BLAS by an order of magnitude. It's sad, because vecLib used to be fairly well optimized ... (in fact it is actually some version of ATLAS which is even more strange ...). My solution has also been to switch to the reference BLAS, which outperforms vecLib on most of the operations I benchmarked, except for crossprod(), which is terribly slow (more than 10x slower than tcrossprod()). I've just tested again with R 2.12.0, and the situation has become even worse: now an explicit matrix multiplication M %*% t(M) -- which used to be fast -- performs as poorly as crossprod(). Any ideas about this? The crossprod() slowdown isn't a Mac problem: I got similar results on a Pentium Dual Core laptop running Ubuntu. If this is a known problem of the reference BLAS, is there any way to work around it? Apart from the speed hiccups, in my benchmarks vecLib BLAS performed consistently slower than the reference BLAS. Is there evidence from other benchmarks / hardware architectures that vecLib can be faster? If not, perhaps the default should be _not_ to use vecLib on Mac? Or perhaps it would be possible to autodetect hardware in the R startup wrapper and select the BLAS that's known to run faster on this setup? I don't think we would want to do that since that would prevent the user from choosing the BLAS they want to use. We will probably abandon vecLib as the default for the next release (more due to its numerical instability issues) and maybe provide all three options (vecLib, R BLAS, ATLAS) for the user to choose from in case they have a machine that can take advantage of it. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] daxpy performance with veclib
On Oct 20, 2010, at 2:18 PM, Michael Spiegel wrote: Hi Mac Special Interest Group folks, We've noticed some curious behavior of the veclib BLAS implementation in the development of the OpenMx library. The daxpy implementation appears to be twice as slow in the veclib implementation as compared to the reference implementation. Yes, that is a known problem (see R-SIG-Mac archives). vecLib fails to use multiple cores on Nehalem-based Mac Pros. If you use ATLAS directly it will work just fine - that's what we recommend on Mac Pros. Cheers, Simon Attached is a test kernel that has been run under both implementations. The kernel consists of repeated calls to daxpy with vectors of varying size. In the output files, the first column is the dimension of the vector. The 2nd-4th column report the runtime in seconds of the kernel; three identical trials per vector size. It may be more appropriate to send this information upstream to the veclib persons. However, I thought it would be of interest to Mac R folks, too. For our own project, our workaround will be to create our own basic implementation of daxpy, and continue to link against the veclib BLAS library so we can get a speedup on dgemm and the other functions. The benchmarks were executed on a Mac Pro with 2 Quad-Core Xeons @ 3 GHz (MacPro2,1) running OS X 10.5.8. It was tested with R 2.12.0 and the same behavior has been observed with R 2.10.1. Thanks, --Michael omxTest.cdaxpy.veclib.resultsdaxpy.refblas.results___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How to determine if a Mac is Nehalem-based
On Oct 20, 2010, at 5:55 PM, Steven McKinney wrote: Hi Mac Gurus, I have been searching the web trying to find out how to determine if my Mac is Nehalem-based. I have not been able to find any discussion about how to determine this, beyond something such as Macs built in early 2009 or similarly vague statements. It's not vague at all, it's MacPro4,1 and MacPro5,1 models (you can use use sysctl hw.model to find out what you have). If in doubt, check on Wikipedia ;) The latter uses the Nehalem architecture but I don't have a specimen of those so I can't confirm that the bug still holds true for those. Cheers, Simon Does anyone know where I can find a description of which Intel chips in a Mac constitute Nehalem-based and what R or Mac-OS scripts, commands etc will yield information on the CPU chip in my Mac so I can make this determination? From About this Mac I get the following information, but I'm unclear on what if anything in such output will reliably show whether my Mac is Nehalem-based. Hardware Overview: Model Name: Mac Pro Model Identifier:MacPro4,1 Processor Name: Quad-Core Intel Xeon Processor Speed: 2.66 GHz Number Of Processors:2 Total Number Of Cores: 8 L2 Cache (per core): 256 KB L3 Cache (per processor):8 MB Memory: 32 GB Processor Interconnect Speed:6.4 GT/s Boot ROM Version:MP41.0081.B08 SMC Version (system):1.39f5 SMC Version (processor tray):1.39f5 Serial Number (system): H00230C320H Serial Number (processor tray): C070183004XDCVHAX Hardware UUID: 482F1E2A-2588-5FA3-80AE-11BE11615B02 Any information appreciated Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] ATLAS BLAS
On Oct 20, 2010, at 7:35 PM, Steven McKinney wrote: I have R 2.11.1 installed (soon will update to R 2.12) and I appear to have a Nehalem-based Mac Pro. I'm trying to find documentation about how to set up R on my Mac so I'm using the ATLAS BLAS. Well, you have to get it [=ATLAS] first. Then it's as easy as pointing the libRblas.dylib symlink to it. I have a binary of ATLAS that you can use if you have Mac OS X 10.6 (Snow Leopard) it's at http://r.research.att.com/libatlas-MacPro.dylib So the copy/paste steps (you have to be admin) are: cd /Library/Frameworks/R.framework/Resources/lib curl -O http://r.research.att.com/libatlas-MacPro.dylib chmod a+x libatlas-MacPro.dylib ln -sfn libatlas-MacPro.dylib libRblas.dylib ## if you want to go back to vecLib cd /Library/Frameworks/R.framework/Resources/lib ln -sfn libRblas.vecLib.dylib libRblas.dylib ## if you want to use R's BLAS (not as fast but more reliable) cd /Library/Frameworks/R.framework/Resources/lib ln -sfn libRblas.0.dylib libRblas.dylib I installed this version of R using the Mac installer R-2.11.1.pkg. Does this installer set up R that uses the ATLAS BLAS, or are there additional steps I need to take to have R use the ATLAS BLAS? Once R is up and running, can anyone tell me how I can determine which BLAS R is using? Indirectly, just look at the output of ls -l /Library/Frameworks/R.framework/Resources/lib/libRblas.dylib Cheers, Simon Any info appreciated. sessionInfo() R version 2.11.1 (2010-05-31) x86_64-apple-darwin9.8.0 locale: [1] en_CA.UTF-8/en_CA.UTF-8/C/C/en_CA.UTF-8/en_CA.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.11.1 Steven McKinney ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Change font size of Console Output
On Oct 19, 2010, at 3:12 PM, Juan Pablo Lewinger wrote: This is has been asked before, yet I can't figure out how to: 1) Change (for the current session and/or permanently) the font size of the console output. Format - Font - Bigger / Smaller key equivalents: Cmd+ and Cmd- The setting is persistent. 2) Permanently change the font size of the console input. I can change the font size of the console input from the format menu but only for the current session. Same as above - input and output are in the same text view and use the same font type and size by default - controlled by the keys above. Cheers, Simon Thanks for any help! R 2.11.1, GUI 1.34 Leopard build 64-bit, Mac OS X 10.6.4 ) sessionInfo() R version 2.11.1 (2010-05-31) x86_64-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 Juan Pablo Lewinger, Ph.D. Assistant Professor Division of Biostatistics Department of Preventive Medicine University of Southern California 1450 Biggy Street, NRT 1509G Los Angeles CA 90033 USA ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Easiest way to install R 2.12.0 on a Mac
On Oct 18, 2010, at 6:20 AM, Richard R. Liu wrote: Hello, Up to now I've reinstalled all packages when upgrading R. Is there an easier way. I'm wondering whether just copying the contents of ~/Library/R/2.11 to ~/Library/R/2.12 followed by updating in Packages Date Package Installer Update All in the R Console (R.app) would do the trick. The whole point of using a version-dependent directories is exactly to prevent the chaos resulting from what you suggest. If you installed package at the system level then you can upgrade using the GUI: Package Installer - Get List - Select Packages from R 2.11 (in the search menu) - Install Selected If you use user-local path like you mentioned above, you can always simply use install.packages(.packages(TRUE,~/Library/R/2.11/library)) Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Easiest way to install R 2.12.0 on a Mac
On Oct 18, 2010, at 9:56 AM, huang min wrote: Hi, Simon, When can the binary version of R2.12.0 for MAC be available? The windows version are already out. You can always get the latest R version from http://r.research.att.com Also if you are impatient you can grab http://r.research.att.com/bin/macosx/R-2.12.0.pkg which is the nightly build of the release. In most cases that becomes the release unless there is a last-minute issue. The CRAN will likely have the official release within a day or so. Cheers, Simon Huang On Mon, Oct 18, 2010 at 9:51 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Oct 18, 2010, at 6:20 AM, Richard R. Liu wrote: Hello, Up to now I've reinstalled all packages when upgrading R. Is there an easier way. I'm wondering whether just copying the contents of ~/Library/R/2.11 to ~/Library/R/2.12 followed by updating in Packages Date Package Installer Update All in the R Console (R.app) would do the trick. The whole point of using a version-dependent directories is exactly to prevent the chaos resulting from what you suggest. If you installed package at the system level then you can upgrade using the GUI: Package Installer - Get List - Select Packages from R 2.11 (in the search menu) - Install Selected If you use user-local path like you mentioned above, you can always simply use install.packages(.packages(TRUE,~/Library/R/2.11/library)) Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] does biOps compile on OSX?
On Oct 14, 2010, at 5:09 PM, Carl Witthoft wrote: There's no OSX binary package for biOps at the repository, and the link to the checklog is broken. The package has some issues with detecting TIFF and more over references it even though its detection fails -- the error log says: ** testing if installed package can be loaded Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared object '/Volumes/Tiger/Builds/Rdev-web/QA/Simon/packages/leopard-universal/results/2.12/biOps.Rcheck/biOps/libs/i386/biOps.so': dlopen(/Volumes/Tiger/Builds/Rdev-web/QA/Simon/packages/leopard-universal/results/2.12/biOps.Rcheck/biOps/libs/i386/biOps.so, 6): Symbol not found: _TIFFClose Referenced from: /Volumes/Tiger/Builds/Rdev-web/QA/Simon/packages/leopard-universal/results/2.12/biOps.Rcheck/biOps/libs/i386/biOps.so Expected in: dynamic lookup ERROR: loading failed While the configuration fails to detect TIFF (because it's using the wrong flags) and yet it still does reference it in the code (but not at link time): checking whether gcc -arch i386 -std=gnu99 accepts -g... yes checking for gcc -arch i386 -std=gnu99 option to accept ISO C89... none needed checking for TIFFOpen in -ltiff... no [...] checking tiff.h usability... yes checking tiff.h presence... yes checking for tiff.h... yes [...] gcc -arch i386 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -o biO ps.so arithmetics.o canny.o convolution.o crop.o edge_detection.o fft_filters.o fft_funcs.o filter.o gaussian.o interpolation.o isodata.o isodata_cluster.o jpegio .o kdtree.o kmeans.o kmeans_enhanced.o kmeans_kdtree.o logics.o luts.o marr_hildreth.o minification.o mirroring.o morphology.o noise_gen.o rotate.o scale.o shenca stan.o tiffio.o translation.o utils.o -lm -ljpeg -lfftw3 -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation There are apparently two bugs in biOps: 1) the TIFF detection uses wrong flags - it fails to add dependencies: configure:2624: checking for TIFFOpen in -ltiff configure:2659: gcc -arch x86_64 -std=gnu99 -o conftest -g -O2 conftest.c -ltiff 5 Undefined symbols: _jpeg_read_raw_data, referenced from: _jpeg_read_raw_data_encap in libtiff.a(tif_ojpeg.o) _TIFFjpeg_read_raw_data in libtiff.a(tif_jpeg.o) _jpeg_write_scanlines, referenced from: _TIFFjpeg_write_scanlines in libtiff.a(tif_jpeg.o) _jpeg_write_tables, referenced from: _TIFFjpeg_write_tables in libtiff.a(tif_jpeg.o) _inflateSync, referenced from: _PixarLogDecode in libtiff.a(tif_pixarlog.o) _ZIPDecode in libtiff.a(tif_zip.o) [...] so it's missing -ljpeg -lz In fact it's checking jpeg and TIFF in the inverse order, so chances are if check for libz was added first, then jpeg and then tiff that it might work properly. 2) it is still referencing libTIFF in the package even though it did not link against libTIFF (I didn't dig deeper to see why - likely issue with setting a conditional or not respecting it). I would suggest contacting the maintainer for the issues to be addressed (CC'd - please, Matias, consider this as a bug report). Cheers, Simon Has anyone built biOps under 10.6.x or 10.5.x ? Actually, the only thing I want right now is the imgConvolve function, so if people have other recommendations for a 2-dimensional convolution function in R (other than writing it myself -- Im lazy today :-) ), I'd be happy to know. thanks Carl ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] problem installing rjags package
Michael, On Oct 9, 2010, at 5:56 PM, Michael Braun wrote: Hi! I am trying to install rjags on my Mac Pro running OSX 10.6.4, and R 2.11.1 (which I compiled myself so I could link to the Intel MKL blas, which I prefer to other options). Just FWIW: CRAN R comes with shared BLAS option enabled and allows easy plug-in of MKL BLAS without the need to re-compile (just use the libRblas.dylib symlink). Note that MKL BLAS is often slower than ATLAS so if your main goal is speed I suggest using ATLAS (or vecLib unless you have Nehalem-type Mac Pro) - it is also easier to handle (both from technical and licensing point of view). Cheers, Simon I was successfully able to install JAGS 2.1.0 through both the binary installer, and compiling from source (I get the same problem either way). But I would like to use the rjags package. When I do install.packages(rjags) I get the folliowing output: * installing *source* package ‘rjags’ ... checking for prefix by checking for jags... /usr/local/bin/jags checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking Console.h usability... yes checking Console.h presence... yes checking for Console.h... yes checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for jags_version in -ljags... yes configure: creating ./config.status config.status: creating src/Makevars configure: creating ./config.status config.status: creating src/Makevars config.status: creating R/unix/zzz.R ** libs *** arch - x86_64 g++ -arch x86_64 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/x86_64 -I/usr/local/include/JAGS -I/opt/intel/Compiler/11.1/089/Frameworks/mkl/Headers -I/Install_Files/MKL_gfortran_interface/include/em64t/lp64-fPIC -m64 -msse4.2 -g -O2 -c jags.cc -o jags.o g++ -arch x86_64 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/opt/intel/Compiler/11.1/089/Frameworks/mkl/Libraries/em64t -L/Users/braunm/Install_Files/MKL_gfortran_interface/lib/em64t -o rjags.so jags.o -lgsl -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lpthread -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation installing to /Users/braunm/.R/Library/rjags/libs/x86_64 ** R ** data ** preparing package for lazy loading ** help *** installing help indices ** building package indices ... Error : .onLoad failed in loadNamespace() for 'rjags', details: call: dyn.load(file, DLLpath = DLLpath, ...) error: unable to load shared library '/Users/braunm/.R/Library/rjags/libs/x86_64/rjags.so': dlopen(/Users/braunm/.R/Library/rjags/libs/x86_64/rjags.so, 10): Symbol not found: _JAGS_NA Referenced from: /Users/braunm/.R/Library/rjags/libs/x86_64/rjags.so Expected in: flat namespace in /Users/braunm/.R/Library/rjags/libs/x86_64/rjags.so ERROR: installing package indices failed * removing ‘/Users/braunm/.R/Library/rjags’ However, when I go to look at the symbols in the jags library, I see braunm4: /usr/local/lib $ nm libjags.dylib |grep JAGS 00098650 S _JAGS_NA 00110338 S _JAGS_NAN 00110348 S _JAGS_NEGINF 00110340 S _JAGS_POSINF 133c t __GLOBAL__I_JAGS_NA and when I try braunm4: /usr/local/lib $ nm libjags.a |grep JAGS U _JAGS_NA U _JAGS_NEGINF U _JAGS_NA U _JAGS_NA 0060 S _JAGS_NA 00b8 B _JAGS_NAN 00c8 B _JAGS_NEGINF 00c0 B _JAGS_POSINF U _JAGS_NA U _JAGS_NEGINF U _JAGS_POSINF U _JAGS_NEGINF U _JAGS_POSINF U _JAGS_NEGINF U _JAGS_NA U _JAGS_NEGINF U _JAGS_NEGINF U _JAGS_NA U _JAGS_NEGINF U _JAGS_POSINF So the jags libraries (both static and dynamic) are in the standard place, and it looks like the
Re: [R-SIG-Mac] lme4 and boot fail checks
On Sep 20, 2010, at 5:19 AM, Reinhold Kliegl wrote: Are these problems possibly related? http://cran.at.r-project.org/web/checks/check_results_lme4.html http://cran.at.r-project.org/web/checks/check_results_boot.html No. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] legend command does nothing
On Sep 18, 2010, at 9:16 PM, Adrian wrote:
I remember missing fonts were raised as a possible culprit when I was having
trouble with text appearing on plots. I checked my Font Book at that time
and performed a resolve duplicates on all of my fonts. Then, as now, I
haven't been able to find any duplicate fonts.
But do you have a working Arial and Helvetica when you look in your font book?
Sometime the fonts can be broken ...
Cheers,
Simon
2010/9/18 Simon Urbanek simon.urba...@r-project.org
Adrian,
missing fonts have cropped up a few times - so far the most common cause
were broken fonts - please check your Font Book for duplicate or broken
fonts (most specifically Arial). Please let me know if that was the cause.
Thanks,
Simon
On Sep 18, 2010, at 7:35 AM, Adrian wrote:
Hello,
I am having problems adding legends to my plots. For example, the
command
at the bottom of this message produces no legend for me. The plot
appears
correctly, but the legend is completely absent. Am I doing something
incorrectly in the syntax of the legend function?
It is possible that this is related to a problem that I posted previously
on
this list: I do not see any text on any graphs unless I explicitly supply
the family=sans argument to any plotting function.
Any advice is appreciated. Thank you,
Adrian Down
quartz()
Y=cbind(loglamt,yp)
matplot(x,Y,
xlab=N(t),ylab=log{N(t+1)/N(t)},main=ttext,
type=c(p,l,l,l,l),pch=21,col=c(black,blue,green,red,
purple),lty=1,lwd=2,family=sans)
legend(topright,c(Data,DI model,Ricker,Theta
Logistic,Allee),pch
=c(21,-1,-1,-1),
col=c(black,blue,green,red,purple),lty=c(blank,solid,solid,
solid,solid),lwd=2,plot=TRUE)
[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] my system refuse to install rgdal
On Sep 17, 2010, at 5:02 PM, Agustin Diez Castillo wrote: gdal-config is in my path apparently it's not for R otherwise you would not see that error (hint: .profile and others are NOT loaded by LS). As the error message suggests you can also provide the full path using --with-gdal-config - have you tried that? Cheers, Simon I'm on 10.6.4 I've tried both at system and at user level with the same result. ¿Any suggestions? ERROR: configuration failed for package ‘rgdal’ * removing ‘/Users/adiez/Library/R/2.10/library/rgdal’ The downloaded packages are in ‘/private/var/folders/cv/cvYrUrtiEiuTpxH6VannjU+++TI/-Tmp-/Rtmp4GLVOJ/downloaded_packages’ * installing *source* package ‘rgdal’ ... gdal-config: gdal-config ./configure: line 1311: gdal-config: command not found Error: gdal-config not found The gdal-config script distributed with GDAL could not be found. If you have not installed the GDAL libraries, you can download the source from http://www.gdal.org/ If you have installed the GDAL libraries, then make sure that gdal-config is in your path. Try typing gdal-config at a shell prompt and see if it runs. If not, use: --configure-args='--with-gdal-config=/usr/local/bin/gdal-config' echo with appropriate values for your installation. ERROR: configuration failed for package ‘rgdal’ * removing ‘/Library/Frameworks/R.framework/Versions/2.10/Resources/library/rgdal’ ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Download for Mac OS X 10.4.11
On Sep 15, 2010, at 11:35 AM, Jan Sutherland wrote: Hello All, Not sure which of the many options on the old download list to use for 10.4.11. Anyone Help? You can use any of the *.dmg files. I guess the latest (R 2.10.1) is probably the best ;). Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Previously installed versions after installing 2.12
Max, please consider reading the R for Mac FAQ (most notably 12.15) and the information displayed as you install R. The latter tells you that the default is to remove your old version and instructs you how to install multiple versions in parallel if that's what you want. The former explains why you need to change the Current version softlink if you want to switch between versions and there is even RSwitch app for that to be had at http://r.research.att.com Cheers, Simon On Sep 15, 2010, at 12:29 PM, Max Kuhn wrote: Everyone, I have a few only versions in /Library: drwxrwxr-x 4 root admin 136 May 13 23:46 2.10 drwxrwxr-x 3 root admin 102 Aug 9 16:00 2.11 drwxrwxr-x 6 root admin 204 Aug 9 16:00 2.12 lrwxr-xr-x 1 root admin4 Aug 9 16:00 Current - 2.12 I need to check that something worked in 2.11.x, but when I run $ /Library/Frameworks/R.framework/Versions/2.11/Resources/bin/R64 R version 2.12.0 Under development (unstable) (2010-08-08 r52687) Copyright (C) 2010 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) Note the dates on the 2.11 and 2.12 paths are both Aug 9 16:00, so I'm guessing that the 2.12 installer over-wrote the 2.11 install. I installed 2.11 again, did my testing, then re-installed with 2.12 pkg file dated today: $ ls -al /Library/Frameworks/R.framework/Versions/ total 8 drwxrwxr-x 6 root admin 204 Sep 15 12:19 . drwxrwxr-x 8 root admin 272 Sep 15 12:19 .. drwxrwxr-x 4 root admin 136 May 13 23:46 2.10 drwxrwxr-x 3 root admin 102 Sep 15 12:19 2.11 drwxrwxr-x 6 root admin 204 Sep 15 12:19 2.12 lrwxr-xr-x 1 root admin4 Sep 15 12:19 Current - 2.12 It looks like it wiped out the 2.11 install again. I know that the labels are Under development and unstable, but it is worth brining up. The OS version is 10.6.4. Thanks, Max ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Help in creating a MacOSX binary of the mapdata package 2.1-3?
On Aug 30, 2010, at 3:46 AM, Jooil Kim wrote:
Hello,
My problem was that I didn't have XCode installed until a few minutes ago,
and I can confirm that compiling from the source works (x86_64 on OSX10.6.4,
R2.11.1 - sorry about that).
Of course it does - you can see that form the logs (sort of since you have
different OS and different architecture and thus not really relevant to the
error). But that is beside the point. The fact that something compiles doesn't
meant it works.
The error codes I pasted on my earlier e-mail were copied from the CRAN, the
log notes on why a Mac binary of the mapdata package wasn't available (
http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/mapdata-00check.html
).
As there's no obvious problem with the source code itself, the problem is
most probably with those that maintain the MacOSX binaries on CRAN.
If programs crash and there is no obvious problem with the source then why do
we bother with debugging? If there was an obvious problem then the author would
have fixed it, don't you think? It's the non-obvious problems that we call
bugs.
The point of checks is to verify (to some degree) that a program works the way
it was designed. That's why a binary of a package failing checks will not get
to CRAN as it doesn't work the way it was designed - to protect users from
non-obvious failures. Now why that should be a problem with those that
maintain the MacOSX binaries is entirely beyond me...
Note that the crash is in a call to maps so the issue could be anywhere from
mapdata, maps to R...
I assume there may be some novice users who might not want to go through the
trouble of trying to compiling source code and much rather install just the
binary versions of packages, and I do hope that the overseers of the MacOSX
binaries would give the compile another try...
Sure - with the same result. That's what the nightly builds do: run checks
every night if a package fails - one try a night ...
Cheers,
Simon
On Mon, Aug 30, 2010 at 3:54 PM, Prof Brian Ripley
rip...@stats.ox.ac.ukwrote:
On Mon, 30 Aug 2010, Jooil Kim wrote:
Hello all,
I recently noticed that the MacOSX binary of the mapdata package ver 2.1-3
wasn't available.
The mapdata package is a useful extension for the maps package, providing
higher-resolution map data.
In contacting package maintainer Ray Brownrigg, (Ray.Brownrigg at
ecs.vuw.ac.nz), I'm told that he is willing to make the fixes necessary,
however does not have the Mac resources to track the bug causing the
problems.
In looking at the log, I get the impression that the actual problem is
minor, in that a problem occurs in checking the examples.
Not being able to run your examples is not 'minor': it is the first test
that the package is installed properly, and 'china' is the first example.
You haven't told us the 'at a minimum information' asked for in the posting
guide. What version of R (including what architecture) are you running?
Have you actually tried compiling from the package sources yourself? It
works for me on i386 and x86_64.
So there is a fair chance simply installing from the sources will work for
you. If you have Xcode installed, all you need to do is
install.packages('mapdata', type = 'source')
library(mapdata)
example(china)
.
Here's a copy-and-paste from the logs below.
==
checking examples ... ERROR
Running examples in 'mapdata-Ex.R' failed.
The error most likely occurred in:
### * china
flush(stderr()); flush(stdout())
### Name: china
### Title: China Map
### Aliases: china chinaMapEnv
### Keywords: datasets
### ** Examples
map('china')
*** caught segfault ***
address 0x30010073, cause 'memory not mapped'
Traceback:
1: .C(maptype, PACKAGE = maps, as.character(mapbase), integer(1))
2: maptype(database)
3: map(china)
aborting ...
==
Does anyone in the Mac group have the skills and time to figure this out
and
contact Ray about a solution?
Sorry, I should really try to do this myself, but I'm still very new at
this...
Thanks,
Jooil
--
#
Jooil Kim
Graduate Student
School of Earth and Environmental Sciences,
Seoul National University
Gwanak Gu Shillim 9 Dong San 56-1
Seoul National Univ. Bld#501, Rm 503
Seoul, Rep. of Korea 151-742
kji2...@gmail.com
tel) 82-2-877-6741
fax) 82-2-885-7164
#
[[alternative HTML version deleted]]
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford,
Re: [R-SIG-Mac] Help in creating a MacOSX binary of the mapdata package 2.1-3?
On Aug 30, 2010, at 8:46 PM, Jooil Kim wrote:
Hi Simon,
First off, I can see that some of my previous comments were very ignorant in
many regards. Having been given further information on the efforts of the
r-project community in maintaining the MacOSX binaries, I sincerely regret
most of my remarks.
That said, I find it strange that not only does the compile work, but so do
all the examples in the mapdata package - the map('china') example, the
source of trouble according to the logs, seems to work OK. As far as I can
tell so far, other users cannot reproduce the bug that's keeping a MacOSX
binary from being generated for CRAN.
I can reproduce it reliably in R CMD check and semi-reliably in a session. The
problem is that it is reproducible with the binary, i.e. there is a non-zero
probability that it will happen. The backtrace points into .C itself -- but
since mapdata itself has no native code it is either an issue in maps or R...
(or mapdata generates something on which maps chokes).
I spent quite some time on it today and still can't pin it down (valgrind shows
nothing), so I can release the binary for mapdata but what this means is that
updates won't be pushed automatically.
Cheers,
Simon
My main purpose was to help point out that there may be a problem, not point
fingers at anyone or be disrespectful for any of the people who put in time
and effort to help maintain R. Once again apologize if some of my sentences
came out that way.
I still hope that a solution could be found, as I believe binary forms of
packages are desirable for most people using R, however I don't think I
should be further wasting the community's valuable time with this issue.
Cheers,
Jooil
On Tue, Aug 31, 2010 at 7:51 AM, Simon Urbanek simon.urba...@r-project.org
wrote:
On Aug 30, 2010, at 3:46 AM, Jooil Kim wrote:
Hello,
My problem was that I didn't have XCode installed until a few minutes ago,
and I can confirm that compiling from the source works (x86_64 on
OSX10.6.4, R2.11.1 - sorry about that).
Of course it does - you can see that form the logs (sort of since you have
different OS and different architecture and thus not really relevant to the
error). But that is beside the point. The fact that something compiles
doesn't meant it works.
The error codes I pasted on my earlier e-mail were copied from the CRAN,
the log notes on why a Mac binary of the mapdata package wasn't available (
http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/mapdata-00check.html
).
As there's no obvious problem with the source code itself, the problem is
most probably with those that maintain the MacOSX binaries on CRAN.
If programs crash and there is no obvious problem with the source then why
do we bother with debugging? If there was an obvious problem then the author
would have fixed it, don't you think? It's the non-obvious problems that we
call bugs.
The point of checks is to verify (to some degree) that a program works the
way it was designed. That's why a binary of a package failing checks will not
get to CRAN as it doesn't work the way it was designed - to protect users
from non-obvious failures. Now why that should be a problem with those that
maintain the MacOSX binaries is entirely beyond me...
Note that the crash is in a call to maps so the issue could be anywhere from
mapdata, maps to R...
I assume there may be some novice users who might not want to go through
the trouble of trying to compiling source code and much rather install just
the binary versions of packages, and I do hope that the overseers of the
MacOSX binaries would give the compile another try...
Sure - with the same result. That's what the nightly builds do: run checks
every night if a package fails - one try a night ...
Cheers,
Simon
On Mon, Aug 30, 2010 at 3:54 PM, Prof Brian Ripley
rip...@stats.ox.ac.ukwrote:
On Mon, 30 Aug 2010, Jooil Kim wrote:
Hello all,
I recently noticed that the MacOSX binary of the mapdata package ver 2.1-3
wasn't available.
The mapdata package is a useful extension for the maps package, providing
higher-resolution map data.
In contacting package maintainer Ray Brownrigg, (Ray.Brownrigg at
ecs.vuw.ac.nz), I'm told that he is willing to make the fixes necessary,
however does not have the Mac resources to track the bug causing the
problems.
In looking at the log, I get the impression that the actual problem is
minor, in that a problem occurs in checking the examples.
Not being able to run your examples is not 'minor': it is the first test
that the package is installed properly, and 'china' is the first example.
You haven't told us the 'at a minimum information' asked for in the posting
guide. What version of R (including what architecture) are you running?
Have you actually tried compiling from the package sources
Re: [R-SIG-Mac] R crash in Terminal.app
On Aug 27, 2010, at 9:27 AM, Konis Kjell wrote: Hello, I am able to consistenly crash R (both 32 and 64 bit) with the following three commands plot(1:10, 1:10) dev.off() install.packages(car) when I run R in Terminal.app. I cannot reproduce it. Can you be more specific about your setup (OS X version, how you compiled R, what is your X11 setup)? Note that native tcltk is not supported, only X11. If I run the above in Terminal I get: plot(1:10, 1:10) dev.off() null device 1 install.packages(car) Warning in install.packages(car) : argument 'lib' is missing: using '/Users/urbanek/Library/R/2.11/library' --- Please select a CRAN mirror for use in this session --- CRAN mirror 1: Australia 2: Austria 3: Belgium 4: Brazil (PR) 5: Brazil (RJ) 6: Brazil (SP 1) 7: Brazil (SP 2) 8: Canada (BC) 9: Canada (NS) 10: Canada (ON) 11: Canada (QC 1)12: Canada (QC 2) 13: Chile14: China (Beijing 1) 15: China (Beijing 2)16: China (Hong Kong) 17: Colombia 18: Denmark 19: France (Toulouse)20: France (Lyon 1) 21: France (Lyon 2) 22: Germany (Berlin) 23: Germany (Goettingen) 24: Germany (Hamburg) 25: Germany (Muenchen) 26: Germany (Nuernberg) 27: Germany (Wiesbaden) 28: Greece 29: Iran 30: Ireland 31: Italy (Milano) 32: Italy (Padua) 33: Italy (Palermo) 34: Japan (Hyogo) 35: Japan (Tsukuba) 36: Korea 37: Netherlands (Amsterdam) 38: Netherlands (Utrecht) 39: New Zealand 40: Norway 41: Poland (Oswiecim)42: Poland (Wroclaw) 43: Portugal 44: Russia 45: Singapore46: Slovakia 1 47: Slovakia 2 48: South Africa 49: Spain (Madrid) 50: Sweden 51: Switzerland 52: Taiwan (Taichung) 53: Taiwan (Taipei 1)54: Taiwan (Taipei 2) 55: Thailand (Bangkog) 56: Thailand (Hatyai) 57: UK (Bristol) 58: UK (London) 59: USA (AZ) 60: USA (CA 1) 61: USA (CA 2) 62: USA (IA) 63: USA (MA) 64: USA (MD) 65: USA (MI) 66: USA (MO) 67: USA (NC) 68: USA (OH) 69: USA (PA 1) 70: USA (PA 2) 71: USA (TN) 72: USA (TX 1) 73: USA (TX 2) 74: USA (WA) Selection: Note that tcltk is not involved at all - and it should not be. So apparently it's something about your setup. Since tcltk is not loaded unless your'e running X11 I tried running your example with X11 running and DISPLAY set in Terminal but that works, too: plot(1:10, 1:10) dev.off() X11 4 Warning message: In dev.off() : Display list redraw incomplete install.packages(car) Warning in install.packages(car) : argument 'lib' is missing: using '/Users/urbanek/Library/R/2.11/library' --- Please select a CRAN mirror for use in this session --- Loading Tcl/Tk interface ... done Cheers, Simon Kjell Warning in install.packages(car) : argument 'lib' is missing: using '/u/smat/konis/Library/R/2.11/library' --- Please select a CRAN mirror for use in this session --- Loading Tcl/Tk interface ... 2010-08-27 15:16:54.628 R[3407:60f] -[NSApplication _setup:]: unrecognized selector sent to instance 0x100559f40 2010-08-27 15:16:54.631 R[3407:60f] An uncaught exception was raised 2010-08-27 15:16:54.632 R[3407:60f] -[NSApplication _setup:]: unrecognized selector sent to instance 0x100559f40 2010-08-27 15:16:54.674 R[3407:60f] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSApplication _setup:]: unrecognized selector sent to instance 0x100559f40' *** Call stack at first throw: ( 0 CoreFoundation 0x7fff874ddcc4 __exceptionPreprocess + 180 1 libobjc.A.dylib 0x7fff8502d0f3 objc_exception_throw + 45 2 CoreFoundation 0x7fff87537140 +[NSObject(NSObject) doesNotRecognizeSelector:] + 0 3 CoreFoundation 0x7fff874afcdf ___forwarding___ + 751 4 CoreFoundation 0x7fff874abe28 _CF_forwarding_prep_0 + 232 5 libtk8.5.dylib 0x000116a08ecb TkpInit + 530 6 libtk8.5.dylib 0x000116980cae Tk_PkgInitStubsCheck + 1938 7 tcltk.so0x000116850fce tcltk_init + 62 8 libR.dylib
Re: [R-SIG-Mac] NetCDF and raster on MAC
On Aug 22, 2010, at 3:14 PM, steven mosher wrote: I'm looking for some examples of how to read a NetCDF file with raster directly. The manual is a bit terse on the matter. The dats in question is a 3D (lon,lat,time) 72*36, 161 bands On the MAC I get a request to load RNetCDF, which is not available in Binary. I found a few mails on geting RNetCDF onto the MAC (and udunits as well) FWIW: the currently supported packages for handling of netCDF are ncdf and ncdf4 - both available for Mac. [I avoid netCDF where I can so I cannot help you with your actual question and can only suggest ncdf docs]. Cheers, Simon Failing a direct method, I suppose, I can just read the file into an array and the turn that into a multi band raster.. TIA [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] [R] lme4 + R 2.11.0 + mac unavailable
On Jul 29, 2010, at 7:51 PM, Martin Maechler wrote: KB == Ken Beath k...@kjbeath.com.au on Wed, 28 Jul 2010 01:19:34 - (GMT) writes: KB On Tue, July 27, 2010 11:07 pm, John Maindonald wrote: Binaries for lme4 are not for the time being available either on CRAN or on r-forge? KB There was a discussion about this on R-Sig-ME. It fails one of the checks KB on the machine used to build the mac packages. It may pass on machines KB with a later version of MacOS, but there didn't seem to be a consensus of KB whether failing the checks was a problem. The underlyign issue seems to remain unresolved. My best guess is still to low-level bugs somewhere in the libraries used. However, to help users, I'm willing to *not* run those tests when *running* on the Mac. What does Sys.info()[[sysname]] return on the Mac, i.e., different versions of R running on the Mac? From grepping around I'd expect it give Darwin in all cases. Is that true? ... why don't you just compare the values with tolerance? That seems to make more sense that to disable the test altogether ... Cheers, Simon Regards, Martin Maechler John Maindonald email: john.maindon...@anu.edu.au phone : +61 2 (6125)3473fax : +61 2(6125)5549 Centre for Mathematics Its Applications, Room 1194, John Dedman Mathematical Sciences Building (Building 27) Australian National University, Canberra ACT 0200. http://www.maths.anu.edu.au/~johnm On 27/07/2010, at 9:57 PM, Martin Maechler wrote: Dear Peter, note that I am CC'ing this reply to the R - Mac mailing list, on which there are knowledgable people for helping you with some of the Mac specific problems (more inline below). On Sun, Jul 25, 2010 at 20:36, Peter Goff peter.t.g...@vanderbilt.edu wrote: Martin, I saw your series of posts on this topic, but sadly I am still unable to install lme4. I am in the nascent stages of learning R and, at this point, I cannot even load the program arm that is key to my program of study (I'm working with Gelman Hill's Data Analysis using Regression and Multilevel/Hierarchical Models to get acclimated to R). Here's my quandary thus far: (1) I download and install R for Macs (version 2.11.1) (2) I try to find lme4 through the Package Installer only to find that it does not exist. (3) I find your string of postings on the web and try to install using: install.packages(lme4, type = source) and I get the following error message: --- Please select a CRAN mirror for use in this session --- (I chose USA, MI) Ok, I assume that's close enough to Vanderbilt .. trying URL 'http://cran.mtu.edu/src/contrib/lme4_0.999375-34.tar.gz' Content type 'application/x-gzip' length 1028012 bytes (1003 Kb) opened URL == downloaded 1003 Kb * installing *source* package ‘lme4’ ... ** libs *** arch - i386 gcc -arch i386 -std=gnu99 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -I/usr/local/include -I/Library/Frameworks/R.framework/Versions/2.11/Resources/library/Matrix/include -I/Library/Frameworks/R.framework/Resources/library/stats/include -fPIC -g -O2 -c init.c -o init.o /bin/sh: gcc: command not found See, that's a clue: 'gcc' is the GNU C compiler and that (and more) are absolutely musts for installing many R packages from source. The readers of R-SIG-Mac will be able to give more exact details, but in order to get a version of gcc (and other tools) working nicely with your version of R, you'll need to install (parts of) the Xcode development tools that Apple provides to you (for free, but you need to get them). Best regards, Martin make: *** [init.o] Error 127 ERROR: compilation failed for package ‘lme4’ * removing ‘/Library/Frameworks/R.framework/Versions/2.11/Resources/library/lme4’ The downloaded packages are in ‘/private/var/folders/ty/tyL1SdtKGlObzhxQbBUTek+++TI/-Tmp-/Rtmpt4fli2/downloaded_packages’ Updating HTML index of packages in '.Library' Warning message: In install.packages(lme4, type = source) : installation of package 'lme4' had non-zero exit status Days and hours later I am at a loss as to how I should proceed. Any advice would be greatly appreciated! Thanks, ~Peter Peter Trabert Goff PhD student Department of Leadership, Policy, and Organizations Vanderbilt University ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] LME4 not loading
On Jul 28, 2010, at 6:34 AM, Alan Kelly wrote: Martin, my experience may only add to the confusion. When I upgraded to 2.11 on my office Mac I had a similar problem when loading lme4 from CRAN. However, I found the package on R-forge and successfully installed it. On trying the same procedure on my home Mac running 2.11.1, this approach fails with the following error (this differs from yours): library(lme4) Loading required package: Matrix Loading required package: lattice Attaching package: 'Matrix' The following object(s) are masked from 'package:base': det Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/Library/Frameworks/R.framework/Resources/library/lme4/libs/i386/lme4.so': dlopen(/Library/Frameworks/R.framework/Resources/library/lme4/libs/i386/lme4.so, 6): Library not loaded: /usr/local/lib/libgfortran.2.dylib Referenced from: /Library/Frameworks/R.framework/Resources/library/lme4/libs/i386/lme4.so Reason: image not found Error: package/namespace load failed for 'lme4' The Rforge is not mapping libgfortran correctly hence the error. You can work around that by installing gfortran from CRAN - but please read on instead. And you will not be able to load arm as this depends on lme4. I have created extra untested repository for this, you can now install lme4 (CRAN version but ignoring check failures) using install.packages(lme4,,http://r.research.att.com/,type='mac.binary.untested') Cheers, Simon Frustrating Regards, Alan Alan Kelly Trinity College Dublin Quoting r-sig-mac-requ...@stat.math.ethz.ch: Send R-SIG-Mac mailing list submissions to r-sig-mac@stat.math.ethz.ch To subscribe or unsubscribe via the World Wide Web, visit https://stat.ethz.ch/mailman/listinfo/r-sig-mac or, via email, send a message with subject or body 'help' to r-sig-mac-requ...@stat.math.ethz.ch You can reach the person managing the list at r-sig-mac-ow...@stat.math.ethz.ch When replying, please edit your Subject line so it is more specific than Re: Contents of R-SIG-Mac digest... ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Question about file.path
On Jul 25, 2010, at 5:42 PM, Riccardo G-Mail wrote: Hi, my name is Riccardo, I'm a PhD student in Soil Science in University of Florence (Italy), and I'm beginning to use R. I work both in a remote server and my own Mac, and so I use /file.path()/ function according to where I must work: /mainDir - file.path( #/Volumes/comune/RICERCA/Odori/ConfrontoDHS-SPME/AnalisiR) #remote server 1 #/Volumes/pesticidi/Ricerca/Odori/ConfrontoDHS-SPME/AnalisiR) #remote server 2 /Users/riccardoromoli/Documents/Università/Tesi PhD/ConfrontoDHS-SPME/AnalisiR) my own Mac dataDir - file.path(mainDir, Dati) workDir - file.path(mainDir, report)/ When I use the /read.table/ function I have this error: /df.AREE - read.table(file.path(dataDir, ORIGINALI, SPME_H2O, AREE.txt), sep = \t, as.is = TRUE, dec=., header= TRUE, fill=TRUE)[,-c(2, 5:15, 17:28, 30:31)] / *Error in file(file, rt) : cannot open this connection In file(file, rt) : cannot open file '/Users/riccardoromoli/Documents/Università/Tesi PhD/ConfrontoDHS-SPME/AnalisiR/Dati/ORIGINALI/SPME_H2O/AREE.txt': No such file or directory* Do you have any suggestion? Well, apparently that directory doesn't exist - that's what R tells you. a) make sure you're running in the right locale (should be UTF-8 to support non-ASCII characters) b) make sure the path actually exists (use drag drop to avoid typing mistakes) Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] JGR and snow leopard
On Jul 19, 2010, at 9:01 AM, Hadley Wickham wrote: Hi all, I just installed JGR (JGR-1.6-SL.dmg). The first time I ran it it installed the packages it needed (successfully as far as I can tell), but when JGR itself opens I get: Loading required package: JGR Loading required package: rJava Loading required package: JavaGD Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/Users/hadley/R/JavaGD/libs/x86_64/JavaGD.so': dlopen(/Users/hadley/R/JavaGD/libs/x86_64/JavaGD.so, 6): Library not loaded: /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libR.dylib Referenced from: /Users/hadley/R/JavaGD/libs/x86_64/JavaGD.so Reason: image not found Error: package 'JavaGD' could not be loaded Loading required package: JGR Loading required package: JavaGD Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/Users/hadley/R/JavaGD/libs/x86_64/JavaGD.so': dlopen(/Users/hadley/R/JavaGD/libs/x86_64/JavaGD.so, 6): Library not loaded: /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libR.dylib Referenced from: /Users/hadley/R/JavaGD/libs/x86_64/JavaGD.so Reason: image not found Error: package 'JavaGD' could Any ideas? That looks fishy - JGR installs packages in the system location by default but you're loading some packages from your home - possibly for the wrong R version. I suspect you have some issue with location of packages (R_LIBS) and are updating the wrong ones - note that JGR uses its own launcher so regular rules on overriding R_LIBS don't work unless you do it when you start JGR (custom R_LIBS are then stored it in the preferences and become permanent) -- [to be precise they actually work but you have to understand at which point you're changing things ...]. So you can check your packages and clean them up or just follow this: 1) delete preferences (~/.JGRprefsrc) to make sure you have a clean start 2) delete any old related packages (optional, but helps to debug package location issues) 3) if you want custom R_LIBS, set it and start the launcher on directly the command line, otherwise just leave it alone and start JGR normally without any overrides Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] distributing a customized R to students?
On Jul 14, 2010, at 9:22 AM, John Fox wrote: Dear all, Could anyone suggest how to prepare a customized R CD to distribute to students? What I do for students using Windows (still the large majority of those in my class) is to prepare an R-for-Windows installer that installs a customized R along with the Rcmdr package and all its dependencies. I'd like to prepare something similar, if possible, for students using Mac OS X. Along with R, the Rcmdr package has many dependencies and requires that X11 and Tcl/Tk for X Windows are installed. It's easily possible - you can use Apple's PackageMaker (that is what we use for official R distributions). Cheers, Simon If it's not possible to create an installer that will install everything necessary in one step, is there another approach to distributing the required components on a CD? The object is to make the installation as simple as possible, since many of my students find software installation challenging. Any suggestions would be appreciated. Thanks, John John Fox Senator William McMaster Professor of Social Statistics Department of Sociology McMaster University Hamilton, Ontario, Canada web: socserv.mcmaster.ca/jfox ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Rcpp 0.8.3 on Mac OS X 10.5.8
On Jul 13, 2010, at 8:13 AM, Ken Knoblauch wrote: Thanks. I'm in mode d'attente... I did not see the exact OS version mentioned anywhere but as Romain pointed out it's working just fine on OS X 10.5.8 with gcc 5577: hagal:~$ gcc --version i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577) 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. hagal:~$ uname -r 9.8.0 [...] * installing *source* package 'Rcpp' ... ** libs *** arch - i386 g++ -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -I../inst/include/ -I/usr/local/include-fPIC -g -O2 -c Date.cpp -o Date.o g++ -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -I../inst/include/ -I/usr/local/include-fPIC -g -O2 -c DateVector.cpp -o DateVector.o g++ -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -I../inst/include/ -I/usr/local/include-fPIC -g -O2 -c Datetime.cpp -o Datetime.o [...] So my only advice really is to re-install Xcode... Cheers, Simon Quoting Romain Francois romain.franc...@dbmail.com: Le 13/07/10 13:59, Ken Knoblauch a écrit : Salut Romain, Thanks for your rapid response. Toujours pas de chance. Just for verification, my gcc [Macintosh-83:~] knoblauch% gcc --version i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577) 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. IIRC, this is the version (both OS and compiler version) that is used on CRAN so there is nothing fundamentally wrong about these. I'm cc'ing the r-sig-mac mailing list where people might have more clues, as I am afraid I'm short :-( Romain [Macintosh-83:~] knoblauch% svn checkout svn://svn.r-forge.r-project.org/svnroot/rcpp/pkg A pkg/RcppExamples ... [Macintosh-83:~] knoblauch% cd pkg [Macintosh-83:~/pkg] knoblauch% R CMD INSTALL -l ~/Library/R/2.11/library/ Rcpp * installing *source* package ‘Rcpp’ ... ** libs *** arch - i386 g++ -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -I../inst/include/ -I/usr/local/include -fPIC -g -O2 -c Date.cpp -o Date.o ../inst/include/Rcpp/internal/export.h: In function 'void Rcpp::internal::export_range__dispatch(SEXPREC*, InputIterator, Rcpp::traits::r_type_primitive_tag)': ../inst/include/Rcpp/internal/export.h:56: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://developer.apple.com/bugreporter for instructions. make: *** [Date.o] Error 1 ERROR: compilation failed for package ‘Rcpp’ * removing ‘/Users/knoblauch/Library/R/2.11/library/Rcpp’ * restoring previous ‘/Users/knoblauch/Library/R/2.11/library/Rcpp’ So, still the same problem. Could this be a Leopard vs Snow Leopard problem? Thanks. best, Ken PS, I'll subscribe shortly, but went ahead and tried your suggestion first. Quoting Romain Francois rom...@r-enthusiasts.com: Bonjour Ken, We usually encourage people to use the mailing list (cc'ed) rather than the maintainer address (you would need to subsribe first) http://lists.r-forge.r-project.org/mailman/listinfo/rcpp-devel I think this was fixed and the version 0.8.4 is on CRAN incoming. Could you try the svn version and let us know if it compiles fine, it certainly does for me on Snow Leopard. $ svn checkout svn://svn.r-forge.r-project.org/svnroot/rcpp/pkg $ R CMD INSTALL Rcpp Thanks for your interest in Rcpp. FWIW, my version of gcc (on snow leopard) is: $ gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659) 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. ... time passes ... Now this does sound familiar and I think we have seen some similar errors when Rcpp was inadvertently built with gcc 4.0 on CRAN Romain Le 13/07/10 13:38, Ken Knoblauch a écrit : Hi, I'm wondering if you can provide any suggestions for installing Rcpp on Mac or whether I should await the appearance of a binary? This is the error message that I get: R CMD INSTALL --no-multiarch -l ~/Library/R/2.11/library/ Rcpp_0.8.3.tar.gz * installing *source* package ‘Rcpp’ ... ** libs *** arch - i386 g++ -arch i386 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -I../inst/include/
Re: [R-SIG-Mac] Compiling problem:
Thanks, Conrad,
finally, I can give you some more targeted suggestions. I'll cover several
issues (those will bite you later), not just the one that breaks.
a) configure
You have the order of check switched - you're first checking for the compiler
(AC_LANG etc.) and only then setting the right one from R. The order should be
reversed since you first need to find the compiler and only then check it.
b) Brownie makefile
The one is really hard-wired so it won't work since you have flags like -m32 in
there so you end up with things like g++ -arch x86_64 -m32 .. which cannot
work. Also compilation should not include $(LNK_OPTIONS) [you don't need them
at all since you're not linking anything anyway]. In fact it would be much
better to just take the flags from R since you are also missing PIC flags and
they will be needed: although you are compiling a static library it will be
linked into a dynamic object so it has to be PIC.
c) Now, the real meat is in the linker flags in RBrownie - and the compiler
actually tells you what the mistake is:
ld: warning: path './brownie_src/libBrownie.a' following -L not a directory
You didn't really mean to sdd the libBrownie.a directory to be the search path
- you really meant to use the library so your configure should read
AC_SUBST([LDFLAGS],[brownie_src/libBrownie.a ${LIBS} ${RCPP_LIB} ])
... and with that it works.
Cheers,
Simon
On Jul 13, 2010, at 2:05 PM, Conrad Stack wrote:
Ah, sorry about that. I'm working off of this branch:
svn checkout http://brownie.googlecode.com/svn/branches/brownie_jcs
brownieTEST
cd brownieTEST
chmod +x build_r
./build_r
That should start the build.
Thanks!
Conrad
On Mon, Jul 12, 2010 at 3:58 PM, Simon Urbanek simon.urba...@r-project.org
wrote:
Conrad,
On Jul 12, 2010, at 4:57 PM, Conrad Stack wrote:
On Sun, Jul 11, 2010 at 12:56 PM, Simon Urbanek simon.urba...@r-project.org
wrote:
On Jul 10, 2010, at 4:55 PM, Conrad Stack wrote:
Hello fellows,
I'm currently developing an R package and having some trouble getting it
to
install on Mac OS (the build process works fine on Windows 7 and Ubuntu
10).
The little prototype that I'm trying to get working compiles a large
amount
of C++ code which is connected to R via Rcpp (0.8.2). The C++ is
compiled
using autoconfig scripts into a static library which is used in Makevars
(in
the src directory). Here is the relevant Makevars line (where libBrownie
is
the static library just compiled):
PKG_LIBS=-s -L. -L./brownie_src -lBrownie -lR -lgsl -lgslcblas -lm
/opt/local/lib/R/library/Rcpp/lib/libRcpp.a
That sounds like a lot of trouble in itself (you should not include any R
flags since that can break and -lR is not what's used on OS X; -s it bad as
well and static libraries are better linked using their name since they
have
lower priority in -l). But it could be really anything including bugs in
your package, so without the actual package I fear we can't help you much.
Thanks Simon, linking the static library using it's name directly and
removing the -lR and -s flags fixed the bus error. Unfortunately, I'm now
getting another error when the package tries to load:
Error in dyn.load(RBrownie.so) :
unable to load shared library
'/Users/conrad/brownie/RBrownie/src/RBrownie.so':
dlopen(/Users/conrad/brownie/RBrownie/src/RBrownie.so, 6): Symbol not
found: __ZTV16NewickTreeWriter
Referenced from: /Users/conrad/brownie/RBrownie/src/RBrownie.so
Expected in: dynamic lookup
Where that function is from the static library (libBrownie.a) which was not
being linked properly from before. I think this is a fairly standard C++
error, but any help would be appreciated. I do know enough to run these
commands:
(from the static library)
nm libBrownie.a | grep __ZTV16NewickTreeWriter:
U __ZTV16NewickTreeWriter
f7a0 S __ZTV16NewickTreeWriter
(from the shared library which R builds):
nm libBrownie.a | grep __ZTV16NewickTreeWriter
U __ZTV16NewickTreeWriter
Unfortunately http://code.google.com/p/brownie/source/checkout doesn't even
compile so I don't think we can help you any further. From experience I would
still bet on the package flags being wrong (it's a bit tedious to debug since
symbols are only resolved at load time, not at link time) but we can't tell
without the package.
Cheers,
Simon
Thanks!
This step seems to work fine and if I run the ./configure script which is
generated from the autoconfig file,
More trouble - you should never run configure by hand because it will
likely use wrong settings (unless it is written such that it attempts to
find R and run it to get flags) - R CMD INSTALL is what you need to use so
the correct architecture, compilers and flags are setup.
Yes, my config script uses R to supply the flags, so running configure seems
to run
Re: [R-SIG-Mac] Compiling problem:
Conrad,
On Jul 12, 2010, at 4:57 PM, Conrad Stack wrote:
On Sun, Jul 11, 2010 at 12:56 PM, Simon Urbanek simon.urba...@r-project.org
wrote:
On Jul 10, 2010, at 4:55 PM, Conrad Stack wrote:
Hello fellows,
I'm currently developing an R package and having some trouble getting it
to
install on Mac OS (the build process works fine on Windows 7 and Ubuntu
10).
The little prototype that I'm trying to get working compiles a large
amount
of C++ code which is connected to R via Rcpp (0.8.2). The C++ is
compiled
using autoconfig scripts into a static library which is used in Makevars
(in
the src directory). Here is the relevant Makevars line (where libBrownie
is
the static library just compiled):
PKG_LIBS=-s -L. -L./brownie_src -lBrownie -lR -lgsl -lgslcblas -lm
/opt/local/lib/R/library/Rcpp/lib/libRcpp.a
That sounds like a lot of trouble in itself (you should not include any R
flags since that can break and -lR is not what's used on OS X; -s it bad as
well and static libraries are better linked using their name since they have
lower priority in -l). But it could be really anything including bugs in
your package, so without the actual package I fear we can't help you much.
Thanks Simon, linking the static library using it's name directly and
removing the -lR and -s flags fixed the bus error. Unfortunately, I'm now
getting another error when the package tries to load:
Error in dyn.load(RBrownie.so) :
unable to load shared library
'/Users/conrad/brownie/RBrownie/src/RBrownie.so':
dlopen(/Users/conrad/brownie/RBrownie/src/RBrownie.so, 6): Symbol not
found: __ZTV16NewickTreeWriter
Referenced from: /Users/conrad/brownie/RBrownie/src/RBrownie.so
Expected in: dynamic lookup
Where that function is from the static library (libBrownie.a) which was not
being linked properly from before. I think this is a fairly standard C++
error, but any help would be appreciated. I do know enough to run these
commands:
(from the static library)
nm libBrownie.a | grep __ZTV16NewickTreeWriter:
U __ZTV16NewickTreeWriter
f7a0 S __ZTV16NewickTreeWriter
(from the shared library which R builds):
nm libBrownie.a | grep __ZTV16NewickTreeWriter
U __ZTV16NewickTreeWriter
Unfortunately http://code.google.com/p/brownie/source/checkout doesn't even
compile so I don't think we can help you any further. From experience I would
still bet on the package flags being wrong (it's a bit tedious to debug since
symbols are only resolved at load time, not at link time) but we can't tell
without the package.
Cheers,
Simon
Thanks!
This step seems to work fine and if I run the ./configure script which is
generated from the autoconfig file,
More trouble - you should never run configure by hand because it will
likely use wrong settings (unless it is written such that it attempts to
find R and run it to get flags) - R CMD INSTALL is what you need to use so
the correct architecture, compilers and flags are setup.
Yes, my config script uses R to supply the flags, so running configure seems
to run okay
Cheers,
Simon
the library builds properly on Mac OS.
The problem manifests when installing the package:
** testing if installed package can be loaded
*** caught bus error ***
address 0x0, cause 'non-existent physical address'
Traceback:
1: dyn.load(file, DLLpath = DLLpath, ...)
2: library.dynam(lib, package, package.lib)
3: loadNamespace(package, c(which.lib.loc, lib.loc), keep.source =
keep.source)
4: doTryCatch(return(expr), name, parentenv, handler)
5: tryCatchOne(expr, names, parentenv, handlers[[1L]])
6: tryCatchList(expr, classes, parentenv, handlers)
7: tryCatch(expr, error = function(e) {call - conditionCall(e)if
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch)))
call - sys.call(-4L)dcall - deparse(call)[1L]
prefix - paste(Error in, dcall, : )LONG - 75Lmsg -
conditionMessage(e)sm - strsplit(msg, \n)[[1L]]w -
14L +
nchar(dcall, type = w) + nchar(sm[1L], type = w)if (is.na
(w))
w - 14L + nchar(dcall, type = b) + nchar(sm[1L],
type = b)if (w LONG) prefix - paste(prefix, \n
, sep = )}else prefix - Error : msg - paste(prefix,
conditionMessage(e), \n, sep = ).Internal(seterrmessage(msg[1L]))
if (!silent identical(getOption(show.error.messages), TRUE))
{
cat(msg, file = stderr()).Internal(printDeferredWarnings())
}invisible(structure(msg, class = try-error))})
8: try({ns - loadNamespace(package, c(which.lib.loc, lib.loc),
keep.source = keep.source)dataPath - file.path(which.lib.loc,
package,
data)env - attachNamespace(ns, pos = pos, dataPath = dataPath,
deps)})
9: library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return
=
TRUE)
10: withCallingHandlers(expr
Re: [R-SIG-Mac] Compiling problem:
On Jul 10, 2010, at 4:55 PM, Conrad Stack wrote:
Hello fellows,
I'm currently developing an R package and having some trouble getting it to
install on Mac OS (the build process works fine on Windows 7 and Ubuntu 10).
The little prototype that I'm trying to get working compiles a large amount
of C++ code which is connected to R via Rcpp (0.8.2). The C++ is compiled
using autoconfig scripts into a static library which is used in Makevars (in
the src directory). Here is the relevant Makevars line (where libBrownie is
the static library just compiled):
PKG_LIBS=-s -L. -L./brownie_src -lBrownie -lR -lgsl -lgslcblas -lm
/opt/local/lib/R/library/Rcpp/lib/libRcpp.a
That sounds like a lot of trouble in itself (you should not include any R flags
since that can break and -lR is not what's used on OS X; -s it bad as well and
static libraries are better linked using their name since they have lower
priority in -l). But it could be really anything including bugs in your
package, so without the actual package I fear we can't help you much.
This step seems to work fine and if I run the ./configure script which is
generated from the autoconfig file,
More trouble - you should never run configure by hand because it will likely
use wrong settings (unless it is written such that it attempts to find R and
run it to get flags) - R CMD INSTALL is what you need to use so the correct
architecture, compilers and flags are setup.
Cheers,
Simon
the library builds properly on Mac OS.
The problem manifests when installing the package:
** testing if installed package can be loaded
*** caught bus error ***
address 0x0, cause 'non-existent physical address'
Traceback:
1: dyn.load(file, DLLpath = DLLpath, ...)
2: library.dynam(lib, package, package.lib)
3: loadNamespace(package, c(which.lib.loc, lib.loc), keep.source =
keep.source)
4: doTryCatch(return(expr), name, parentenv, handler)
5: tryCatchOne(expr, names, parentenv, handlers[[1L]])
6: tryCatchList(expr, classes, parentenv, handlers)
7: tryCatch(expr, error = function(e) {call - conditionCall(e)if
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch)))
call - sys.call(-4L)dcall - deparse(call)[1L]
prefix - paste(Error in, dcall, : )LONG - 75Lmsg -
conditionMessage(e)sm - strsplit(msg, \n)[[1L]]w - 14L +
nchar(dcall, type = w) + nchar(sm[1L], type = w)if (is.na(w))
w - 14L + nchar(dcall, type = b) + nchar(sm[1L],
type = b)if (w LONG) prefix - paste(prefix, \n
, sep = )}else prefix - Error : msg - paste(prefix,
conditionMessage(e), \n, sep = ).Internal(seterrmessage(msg[1L]))
if (!silent identical(getOption(show.error.messages), TRUE)) {
cat(msg, file = stderr()).Internal(printDeferredWarnings())
}invisible(structure(msg, class = try-error))})
8: try({ns - loadNamespace(package, c(which.lib.loc, lib.loc),
keep.source = keep.source)dataPath - file.path(which.lib.loc, package,
data)env - attachNamespace(ns, pos = pos, dataPath = dataPath,
deps)})
9: library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return =
TRUE)
10: withCallingHandlers(expr, packageStartupMessage = function(c)
invokeRestart(muffleMessage))
11: suppressPackageStartupMessages(library(pkg_name, lib.loc = lib,
character.only = TRUE, logical.return = TRUE))
12: doTryCatch(return(expr), name, parentenv, handler)
13: tryCatchOne(expr, names, parentenv, handlers[[1L]])
14: tryCatchList(expr, classes, parentenv, handlers)
15: tryCatch(expr, error = function(e) {call - conditionCall(e)if
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch)))
call - sys.call(-4L)dcall - deparse(call)[1L]
prefix - paste(Error in, dcall, : )LONG - 75Lmsg -
conditionMessage(e)sm - strsplit(msg, \n)[[1L]]w - 14L +
nchar(dcall, type = w) + nchar(sm[1L], type = w)if (is.na(w))
w - 14L + nchar(dcall, type = b) + nchar(sm[1L],
type = b)if (w LONG) prefix - paste(prefix, \n
, sep = )}else prefix - Error : msg - paste(prefix,
conditionMessage(e), \n, sep = ).Internal(seterrmessage(msg[1L]))
if (!silent identical(getOption(show.error.messages), TRUE)) {
cat(msg, file = stderr()).Internal(printDeferredWarnings())
}invisible(structure(msg, class = try-error))})
16: try(suppressPackageStartupMessages(library(pkg_name, lib.loc = lib,
character.only = TRUE, logical.return = TRUE)))
17: do_install_source(pkg_name, instdir, pkg, desc)
18: do_install(pkg)
19: tools:::.install_packages()
aborting ...
/opt/local/lib/R/bin/INSTALL: line 34: 1357 Doneecho
'tools:::.install_packages()'
1358 Bus error | R_DEFAULT_PACKAGES= LC_COLLATE=C
Re: [R-SIG-Mac] R mobile: iOS
On Jul 9, 2010, at 4:31 PM, Etienne Low-Décarie wrote: Good day, iOS devices (iPhone,iPod and iPad) can be amazing tools, expanding the realm of R usage (to the field even!), and it is already possible to run R on a host computer through command line (through SSH apps for example, with no script editor or graphical output). I was wondering if R related software was being developed for this operating system. I am posting these suggestions to this list, as porting software to iOS is similar to porting software to OS X. Porting is the least problem since that is done (for R) for quite some time now (as you can read int this list). The main issues concern the Apple restrictions on applications which essentially rule out R to be ever used under those conditions. That said, there are several remote R GUIs written for OS X so it should not be too hard to revive them and switch from Cocoa to UIKit. There are also web-based approaches for the iOS already although not something I would recommend for several reasons including security and flexibility. Cheers, Simon Suggested R related iOS software include: •Directly ported R-help file •Library of graph examples •R script editor •R mobile app based on similar software available for MatLab (http://www.mathworks.com/mobile/), desired for Mathematica (http://quernstone.com/archives/2008/07/mathematica-for.html) •R mobile helper app (on host computer) •native R mobile (a crippled native R, SpaceTime pulls off something similar, http://www.spacetime.us/) ? Thank you and have an excellent day, Etienne Low-Décarie PhD student Bell Lab and Fussmann Lab McGill University http://etienne.webhop.org/ ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How close to the bleeding edge?
Eric, On Jul 2, 2010, at 5:21 PM, Eric Ditwiler wrote: I like to do all my upgrades at once and then leave well enough alone for a while. My hard drive died so I had them put 10.6.4 on my iMac when they resurrected it. After some finagling my guys were able to get rattle to run with GTK 2.18.5 under R64 2.11. I was able to get lattistist to run under rattle but not rggobi--though regular GGobi runs. My guys want me to go back to 32 bit R2.10 but I am inclined to think that this will sort itself out in the next few months. Does anyone have any insights on how long it takes to make everything play together nicely? What makes you think they don't? Can you be more specific, please? To my knowledge rggobi works nicely in 64-bit for years (and is trivial to install for some time, too) so your comments are rather startling ... I don't use rattle nor latticist (assuming that is the package you meant) myself but AFAICS both binaries work in 64-bit just fine and others are using it so I'm not quite sure what distinguishes you from other users that those package should not play nicely in your presence ... Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How close to the bleeding edge?
On Jul 3, 2010, at 8:13 AM, Hadley Wickham wrote: Hi Eric, Unfortunately it's unlikely that we're going to have a 64-bit version of ggobi ready in the near future. We run it by open R in 32-bit mode: R --arch=i386. Uh, huh? The official CRAN binary *is* 64-bit: http://r.research.att.com/libs/ggobi-2.1.8-darwin9-bin3.tar.gz Cheers, Simon Hadley On Fri, Jul 2, 2010 at 4:21 PM, Eric Ditwiler eric_ditwi...@hmc.edu wrote: I like to do all my upgrades at once and then leave well enough alone for a while. My hard drive died so I had them put 10.6.4 on my iMac when they resurrected it. After some finagling my guys were able to get rattle to run with GTK 2.18.5 under R64 2.11. I was able to get lattistist to run under rattle but not rggobi--though regular GGobi runs. My guys want me to go back to 32 bit R2.10 but I am inclined to think that this will sort itself out in the next few months. Does anyone have any insights on how long it takes to make everything play together nicely? Eric Ditwiler Director, Academic Operations Harvey Mudd College 909-607-3134 ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Trouble compiling Rcpp from source
Adam, the correct way to specify custom linking flags is via PKG_LIBS so try that (more comments inline). Cheers, Simon On Jun 29, 2010, at 5:42 PM, Adam D. I. Kramer wrote: Hi, I tried to install the source version of Rcpp under 64-bit R 2.11.1, which I had compiled myself under OS 10.6.4. The install.packages() run failed, however, with this error: g++ -arch x86_64 -o libRcpp.dylib Date.o DateVector.o Datetime.o DatetimeVector.o Dimension.o DottedPair.o Environment.o Evaluator.o Formula.o Function.o Language.o Module.o Pairlist.o Promise.o RObject.o RcppCommon.o RcppDate.o RcppDateVector.o RcppDatetime.o RcppDatetimeVector.o RcppFrame.o RcppFunction.o RcppList.o RcppNumList.o RcppParams.o RcppResultSet.o RcppStringVector.o RcppStringVectorView.o S4.o Symbol.o WeakReference.o coerce.o debugging.o exceptions.o posixt.o r_cast.o -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress-lintl -Wl,-framework -Wl,CoreFoundation ld: library not found for -lintl collect2: ld returned 1 exit status make: *** [libRcpp] Error 1 ERROR: compilation failed for package 'Rcpp' * removing '/usr/local/lib/R/library/Rcpp' ...libintl could not be found. Well, shoot--I have that. It's in /sw/lib. So, I tried setting LDFLAGS, I tried setting --configure-vars=LDFLAGS=-L/sw/lib, I tried setting configure-args the same way, I added /sw/lib to my LD_LIBRARY_PATH environment variable...pretty much everything, but when I install.packages() the above command does not change even though it is clearly linking. That is clear - LD_LIBRARY_PATH has no effect on OS X and the package has no configure script so there is no point in trying to set configure-vars ;). I would also note that LDFLAGS=-L/sw/lib is actually included in my call to ./configure when building R in the first place... Your'e asking for trouble with that. Although it is unrelated to your issue if you have fink setup R's configure will pick it up automatically so better stick to that. so my hand-compiled version of R should well know where to look for libraries. So my question to the list: Is there some specific way to make R pass the correct flags to the compiler in this case? I can't figure one out. It is well documented in R-exts section 1.2.1. Just for completeness (not related to your case), packages with configure scripts should respect the usual autoconf settings such as CFLAGS, LIBS etc. and pass them to Makevars as PKG_LIBS etc., but there are some that are badly written and don't. (I also note that if I download the source, unarchive it, and tweak the makefile to hard-code -L/sw/lib into the path, the package installs just fine and works...so the problem is in how install.packages() is working.) So, could someone please explain to me how to get R CMD INSTALL or install.packages() on OSX to add linker flags that I would like to specify? Or if this is a problem with R in general, or a problem with Rcpp in general, please kindly let me know. I doubt that I am the only person having this trouble. Cordially, Adam Kramer ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] lme4 package for Mac not available
On Jun 24, 2010, at 7:33 PM, Gisela Böhm wrote: Dear R-Mac people, I am using R on a Mac, and would need the lme4 package. I saw on the help-list that it has been unavailable for reasons I do not understand. It fails make check. CRAN is not distributing binaries of packages that fail checks since it may deliver incorrect results. You can still install it from sources install.packages(lme4,type='source') if you want to use it anyway (see R for Mac FAQ for the necessary tools). Is there a chance that lme4 will be available soon again for the Mac? They will be available when lme4 is fixed to pass the checks. Given that the issue is there for over a year I would not hold my breath. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Plotting problems - where's the text?
On Jun 25, 2010, at 12:26 PM, Nicholas R Frazier wrote: Hi: I've been using R on my MacBook (OS X 10.6.3, 2 GHz Intel Core Duo) for a couple of months now. I've noticed that whenever I plot a graph, the output never shows indices for the axes. It shows tick marks on the side of the graph, but no text. e.g. test = merge(seq(1:10), seq(1:20)) plot(test) shows the correct plot, with 4 tick marks up the side of the Y axis, 5 tick marks down the X axis, but NO text or numbers anywhere. Please check your fonts (Applications - Font Book) and make sure Arial and Helvetica are not disabled or corrupted (those are the defaults - if you changed your font settings in R check the corresponding fonts). Cheers, Simon As another example, a pairs() plot doesn't show any text along the diagonal boxes, as it should. Help? Thanks, Nick Frazier [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Hang with help link to pdf overview file
David, On Jun 15, 2010, at 3:30 PM, David Winsemius wrote: A post to r-help today prompted me to see if I could reproduce the problems the poster was having with a hang as a result of access to a pdf vignette for package zoo. I was not able to get a hang with using (from the GUI): vignette(zoo) but I was able to get a hang when access the zoo help Index and choosing the overview link at the top of the help browser page. The OP was using R 2.11.1, while I was using R 2.10.1. We both were using OSX 10.5.8. Do you have any Adobe plugins installed? They are known to be buggy and crash at times. The standard OS X pdf viewers work just fine. In case you have no plugins - can you, please, describe in detail how to reproduce the issue? (GUI/ command line, exact version) I was following your steps in the GUI [R.app GUI 1.34 (5589) i386-apple-darwin9.8.0] and it was working just fine on 10.6.3 (I don't have access to 10.5 at the moment). Thanks, Simon I then updated to yesterdays stable R 2.11.1 from the ATT page and can still get the segfault, although it no longer hangs. It lets me exit gracefully and even lets me copy portions of the console window: ?zoo starting httpd help server ... done *** caught segfault *** address 0x101e9, cause 'memory not mapped' Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace Selection: The original r 2.10.1 setup sessionInfo() R version 2.10.1 RC (2009-12-09 r50695) x86_64-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] zoo_1.6-3 lattice_0.18-3 loaded via a namespace (and not attached): [1] grid_2.10.1 tools_2.10.1 The error report from R 2.10.1 is available if anyone is interested. -- David Winsemius, MD West Hartford, CT ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Greek font lost
David, which graphics device and which OS are you talking about? For Quartz it is the Symbol font that is used (if I remember correctly) - please check your Font Book and make sure it's not disabled. Cheers, Simon On Jun 15, 2010, at 5:17 PM, David Winsemius wrote: Dear MacRs; I have been having this problem for a while, but thought that when I updated to 2.11.1 that it might get fixed, but just did that and it persists. When I use plotmath functions, I see little empty boxes where I should be seeing theta's and phi's: require(graphics) # the first plotmath example x - seq(-4, 4, len = 101) y - cbind(sin(x), cos(x)) matplot(x, y, type = l, xaxt = n, main = expression(paste(plain(sin) * phi, and , plain(cos) * phi)), ylab = expression(sin * phi, cos * phi), # only 1st is taken xlab = expression(paste(Phase Angle , phi)), col.main = blue) axis(1, at = c(-pi, -pi/2, 0, pi/2, pi), labels = expression(-pi, -pi/2, 0, pi/2, pi)) # -- no phi's or pi's or warnings --- How do I identify which library should be replaced or repaired or added to my PATH or which option set? Have searched archives and FAQs, but maybe I'm not using same terms or understanding what I am being told. -- David Winsemius, MD West Hartford, CT sessionInfo() R version 2.11.1 Patched (2010-06-14 r52281) x86_64-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] lattice_0.18-8 loaded via a namespace (and not attached): [1] grid_2.11.1 tools_2.11.1 ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] tcltk problem
Thanks for sharing with us that you forgot to install Tcl/Tk - not that we really need to know that. Did you mean to ask some question perhaps? Cheers, Simon On Jun 11, 2010, at 2:21 PM, Michael Kubovy wrote: library(tcltk) Loading Tcl/Tk interface ... Error : .onLoad failed in loadNamespace() for 'tcltk', details: call: dyn.load(file, DLLpath = DLLpath, ...) error: unable to load shared library '/Library/Frameworks/R.framework/Resources/library/tcltk/libs/x86_64/tcltk.so': dlopen(/Library/Frameworks/R.framework/Resources/library/tcltk/libs/x86_64/tcltk.so, 10): Library not loaded: /usr/X11R6/lib/libX11.6.dylib Referenced from: /usr/local/lib/libtk8.5.dylib Reason: image not found Error: package/namespace load failed for 'tcltk' I had installed tcltk-8.5.5-x11.dmg X11 is running sessionInfo() R version 2.11.1 (2010-05-31) x86_64-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] grid_2.11.1 lattice_0.18-8 latticeExtra_0.6-11 [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] tcltk problem
Ooops - my apologies - I missed that the output actually included some comment inside - it looked like a plain R output. It seems you're missing X11 - please read the FAQ on how to install it. Cheers, Simon On Jun 11, 2010, at 3:45 PM, Simon Urbanek wrote: Thanks for sharing with us that you forgot to install Tcl/Tk - not that we really need to know that. Did you mean to ask some question perhaps? Cheers, Simon On Jun 11, 2010, at 2:21 PM, Michael Kubovy wrote: library(tcltk) Loading Tcl/Tk interface ... Error : .onLoad failed in loadNamespace() for 'tcltk', details: call: dyn.load(file, DLLpath = DLLpath, ...) error: unable to load shared library '/Library/Frameworks/R.framework/Resources/library/tcltk/libs/x86_64/tcltk.so': dlopen(/Library/Frameworks/R.framework/Resources/library/tcltk/libs/x86_64/tcltk.so, 10): Library not loaded: /usr/X11R6/lib/libX11.6.dylib Referenced from: /usr/local/lib/libtk8.5.dylib Reason: image not found Error: package/namespace load failed for 'tcltk' I had installed tcltk-8.5.5-x11.dmg X11 is running sessionInfo() R version 2.11.1 (2010-05-31) x86_64-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] grid_2.11.1 lattice_0.18-8 latticeExtra_0.6-11 [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] RQuantLib missing binaries
On Jun 10, 2010, at 2:15 AM, Prof Brian Ripley wrote: On Wed, 9 Jun 2010, Kyle Matoba wrote: Just wondering if there was any plans to get this up and running again: http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/RQuantLib-00install.html If not, I will compile it myself. You may not find it easy. The issue is that RQuantLib depends on QuantLib, in fact on a recent version of QuantLib (later than the one in the current Fedora distribution, for example). QuantLib is a large C++ suite of programs, and I've failed to compile it on Linux in the past, and when I have succeeded the package failed its own tests. I don't see anything in the changelog to indicate that this is deliberate. Could whomever is compiling for macs look into this? It is done by Simon Urbanek's autobuiilder. I don't see anything which indicates that it is not deliberate If you look at the packages which are not being built by the Mac autobuiilder you will see three main reasons why: (a) the package fails its tests, e.g. lme4 (b) the package depends on other packages which are not available on the build machine, usually from BioC or OmegaHat. (c) the package depends on external software. RQuantLib is in category (c), and very few such packages are being built (not even Simon's own packages GDD and proj4). If a package depends on external software it is built only if a) there is some demand for it and b) the dependencies can be built into self-contained static libraries with reasonably moderate effort. Now, since a) has been satisfied by this e-mail I was able to compile QuantLib and it is now available on the CRAN machine, but as Brian pointed out RQuantLib doesn't even pass its own checks, so despite our efforts there will be no binary. If you still want to build it despite it failing its own checks, you can get the QuantLib binary from http://r.research.att.com/libs/ (beware, it's huge) and put the boost directory (containing the headers) from the Boost source distribution in /usr/local/include and you'll be able to compile RQuantLib for yourself. Cheers, Simon If you look at the CRAN test logs, the only platform on which RQuantLib is being installed is 32-bit Windows (not even Debian on which it is developed) -- and that is because the author supplied a pre-compiled Windows version of QuantLib. I suspect you seriously underestimate the work which goes into providing R binary packages. I know (I used to do it on Windows and still contribute there) just how thankless (literally and metaphorically) it is. -- 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-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] cairoDevice and GTK under MacOS
On Jun 5, 2010, at 12:03 AM, John Maindonald wrote: Arising from my recent interchange with Professor Ripley, it seems that there is no current binary for cairoDevice that works under R 2.11.0 or 2.11.1. Seems?!? Based on what?!? Brian said clearly that there is a binary and it works for him -- so it does for me! You never told us what *you* are using so there is not much we can do for you - from the output it seemed that you are using the wrong packages with wrong R versions so this is not about CRAN at all. His comments were based on the assumption that you are trying to build something for yourself because the CRAN packages work fine. Cheers, Simon This is in spite of the current CRAN package check results that have OK for cairoDevice under r-release MacOS X ix86 With each new release of R (and maybe release of OSX), there seems a sizeable risk that the cairoDevice/GTK combination will fail. Is cairoDevice/GTK in for the long haul? Or is it likely to be superseded by other GUI interface approaches? If it is in for the long haul, what are the odds of getting quickly to a point where one can have confidence that it will be usable under OSX when a new version of R appears? This is not a criticism of the excellent work that has gone into building cairoDevice/GTK. Restriction of some software to some systems has to be accepted as a fact of life, especially where there is a large element of innovation. Rather, it is a request for any insight that may be available from those on this list who have some limited ability to peer into the future, or even actual knowledge of the future! I guess that some part of the answer will in due course come from commercial users of R. What is available on the Mac may become more important now that Google is, apparently, giving up support internally for use of Windows systems. http://www.ft.com/cms/s/2/d2f3f04e-6ccf-11df-91c8-00144feab49a.html John Maindonald email: john.maindon...@anu.edu.au phone : +61 2 (6125)3473fax : +61 2(6125)5549 Centre for Mathematics Its Applications, Room 1194, John Dedman Mathematical Sciences Building (Building 27) Australian National University, Canberra ACT 0200. http://www.maths.anu.edu.au/~johnm ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] .Last( ) taking keyboard input hangs on command-Q
On May 31, 2010, at 11:22 PM, Day, Roger S wrote: Dear Colleagues, The recent change to R.app disabling q() and requiring command-Q or the equivalent is well motivated. However, it introduces a new problem for a user (like me) who has a .Last() calling for user input, e.g. dialogs on choosing final actions to be taken. Please use R 2.11.1 as this has been changed for some time and report if the issue still exists (with a reproducible example). Thanks, Simon After command-Q, the console cannot accept keyboard input, and clicking on any of the buttons Don't Save, Save does nothing. Clicking Cancel works, but once you've clicked Don't Save or Save clicking Cancel no longer does anything. Then R.app has to be killed the ungracious way. Thoughts? Thanks. -- version _ platform i386-apple-darwin9.8.0 arch i386 os darwin9.8.0 system i386, darwin9.8.0 status major 2 minor 11.0 year 2010 month 04 day22 svn rev51801 language R version.string R version 2.11.0 (2010-04-22) R.app GUI 1.33 (5582 Leopard build 32-bit Roger Day University of Pittsburgh Departments of Biomedical Informatics and Biostatistics University of Pittsburgh Cancer Institute University of Pittsburgh Molecular Medicine Institute - Room 310, Suite 301 Cancer Pavilion (CNPAV) 5150 Centre Ave. Pittsburgh, PA 15232 e-mail: da...@pitt.edu cell phone 412-609-3918 assistant: Lucy Cafeo: (412) 623-2952 ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Oops --- still have problems building R from source.
On May 27, 2010, at 6:28 PM, Rolf Turner wrote: On 28/05/2010, at 8:32 AM, Simon Urbanek wrote: SNIP But now, seriously, why don't use just follow the instructions and do exactly the following (copy/paste): rm -rf /tmp/build mkdir /tmp/build cd /tmp/build curl -O http://cran.stat.auckland.ac.nz/src/base/R-2/R-2.11.0.tar.gz tar fxz R-2.11.0.tar.gz mkdir R-x86_64 cd R-x86_64 ../R-2.11.0/configure r_arch=x86_64 CC=gcc -arch x86_64 \ CXX=g++ -arch x86_64 F77=gfortran -arch x86_64 \ FC=gfortran -arch x86_64 OBJC=gcc -arch x86_64 \ --x-includes=/usr/X11/include --x-libraries=/usr/X11/lib make -j`sysctl -n hw.ncpu` Your only technical issue was that fink was messing up your system, but now that it's gone, all you need to do is to use the regular instructions from FAQ/R-admin like all other people. Well, that worked. At last. Thank you. But I ***do*** follow instructions. All I'll say is that a simple search in the archives is the first thing anyone should do before posting here and if one did it would save a lot of time for everyone: https://stat.ethz.ch/pipermail/r-sig-mac/2009-September/006470.html But don't plan to comment on this thread further. Cheers, Simon I had been following instructions, and they weren't working. These instructions are slightly/subtly different from what I had previously been told to do. As to the ``regular instructions from FAQ/R-admin'' --- that's all very well if you know where to look and what the relevant issues are. When you don't, it makes searching for a needle in a haystack trivial by comparison. Thanks again for getting my problem sorted. cheers, Rolf Turner ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. This e-mail has been scanned and cleared by MailMarshal www.marshalsoftware.com ## ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Oops --- still have problems building R from source.
On May 27, 2010, at 3:58 PM, Rolf Turner wrote: On 28/05/2010, at 2:56 AM, Berend Hasselman wrote: SNIP (R. T.): Wound up getting: . . . gcc -arch x86_64 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -o R_X11.so dataentry.o devX11.o rotated.o rbitmap.o -lSM -lICE -lX11 -lXt -lXmu -L../../../lib -lR -Wl,-framework -Wl,CoreFoundation ld: library not found for -lSM collect2: ld returned 1 exit status make[4]: *** [R_X11.so] Error 1 make[3]: *** [R] Error 2 make[2]: *** [make.X11] Error 2 make[1]: *** [R] Error 1 make: *** [R] Error 1 What is the ``-lSM'' business all about? What is ``SM''? How do I get the missing library? Psigh! :-( You had the same thing some iterations ago. -lSM tells the linker to link against libSM.dylib (in this case; because of the -dynamiclib if i am correct). This .dylib is in /usr/X11/lib You may have forgotten to put the line LIBS=-L/usr/X11/lib into the config.site file. I can't think of anything else. Dang. This is discouraging. The line ``LIBS=-L/usr/Xll/lib'' is definitely in config.site. :-( You do realize that it's supposed to be X11 not Xll, right? But now, seriously, why don't use just follow the instructions and do exactly the following (copy/paste): rm -rf /tmp/build mkdir /tmp/build cd /tmp/build curl -O http://cran.stat.auckland.ac.nz/src/base/R-2/R-2.11.0.tar.gz tar fxz R-2.11.0.tar.gz mkdir R-x86_64 cd R-x86_64 ../R-2.11.0/configure r_arch=x86_64 CC=gcc -arch x86_64 \ CXX=g++ -arch x86_64 F77=gfortran -arch x86_64 \ FC=gfortran -arch x86_64 OBJC=gcc -arch x86_64 \ --x-includes=/usr/X11/include --x-libraries=/usr/X11/lib make -j`sysctl -n hw.ncpu` Your only technical issue was that fink was messing up your system, but now that it's gone, all you need to do is to use the regular instructions from FAQ/R-admin like all other people. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problem with readline when building R from source.
On May 20, 2010, at 22:20, Rolf Turner r.tur...@auckland.ac.nz wrote: On 21/05/2010, at 1:46 PM, Simon Urbanek wrote: Rolf, you have broken fink is /sw -- remove it (or move aside) and all should be well :) Psigh. I'm sure this is getting tedious for you ... but where else can I turn? I did: cd /sw sudo mv fink fink.broken Lol! Ok, back to monosyllabic instructions - run: sudo mv /sw /sw.orig Fink is /sw, what you moved is just a random script inside fink. Cheers, Simon Then I tried the ./configure trick again. Same error message as before. Any other ideas? :-( cheers, Rolf ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. This e-mail has been scanned and cleared by MailMarshal www.marshalsoftware.com ## ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problem with readline when building R from source.
On May 21, 2010, at 1:08 AM, Rolf Turner wrote: On 21/05/2010, at 4:26 PM, Berend Hasselman wrote: On 21-05-2010, at 04:20, Rolf Turner wrote: On 21/05/2010, at 1:46 PM, Simon Urbanek wrote: Rolf, you have broken fink is /sw -- remove it (or move aside) and all should be well :) Psigh. I'm sure this is getting tedious for you ... but where else can I turn? I did: cd /sw sudo mv fink fink.broken Then I tried the ./configure trick again. Same error message as before. Any other ideas? :-( I believe Simon meant: remove or rename /sw and get rid of references to /sw/... in PATH I believe you're right! I renamed /sw and did the ./configure thing. That got me past the readline problem. YAY!!! But then a new problem reared it's ugly little head. BOOO!!! . . . checking for Fortran 77 libraries of gfortran... -L/usr/local/lib -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3 -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.3/../../.. -lgfortranbegin -lgfortran checking how to get verbose linking output from gcc -std=gnu99... -v checking for C libraries of gcc -std=gnu99... -lcrt1.10.6.o -L/usr/local/lib -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../../i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/../../.. -lSystem checking for dummy main to link with Fortran 77 libraries... rm: conftest.dSYM: is a directory none checking for Fortran 77 name-mangling scheme... rm: conftest.dSYM: is a directory unknown configure: WARNING: unknown Fortran name-mangling scheme checking whether gfortran appends underscores to external names... unknown configure: error: cannot use Fortran Any idea what the devil is going on here? I'm getting very frustrated. As usual. :-) I bet you are using 32-bit Fortran while using 64-bit gcc for everything else (see this list). You have two options: use F77=gfortran -arch x86_64 FC=gfortran -arch x86_64 or use the Leopard Fortran for Xcode instead of the old Tiger Fortran. Cheers, Simon cheers, Rolf Turner ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. This e-mail has been scanned and cleared by MailMarshal www.marshalsoftware.com ## ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] R.app 2.11.0 GUI crashes on startup
Steve, On May 17, 2010, at 7:50 PM, Steve Abrams wrote: I downloaded the current Mac OS X version of R today (2.11.0and, when I try to launch it, the icon bounces in my Dock for about 55 seconds then disappears from my Dock. Following the FAQ, I tried uninstalling it and reinstalling it ... same thing. I also tried deleting the .RData and .Rhistory files ... same thing. I can launch R from the terminal so, still following the FAQ, Iʻm sending you the attached Crash Report: The issue is caused by a history file. Now, I'm a bit surprised that deleting ~/.Rhistory did not resolve it -- possibly because you're using a custom history filename? Check the history file you use -- run this Terminal: defaults read org.R-project.R 'History file path used for R type history files' and move/delete the corresponding file. Actually, before you delete it, would you consider sending it to me so I can try to track the cause? Thanks, Simon R_2010-05-17-164020_hanalab.crash thanks! steve Steve Abrams, PhD| Fingers: sabr...@ics.uci.edu Interactive and | Eyes: 5204 DBH Collaborative Technologies | Mouth: (ask me) School of Information and Computer Sciences, Dept. Informatics Irvine, CA 92697-3425 | AIM/YIM/Skype/GIM: ucisteveabrams http://www.ics.uci.edu/~sabrams ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problem with readline when building R from source.
On May 20, 2010, at 8:33 PM, Rolf Turner wrote: I (just now) attempted to build an older version of R (2.10.1) from source. The ./configure step came to a halt with an error: configure: error: --with-readline=yes (default) and headers/libs are not available In the past I had been able to build R from source with no problems. A short time ago, after installing R 2.11.0 (and having some problems with x11() plotting) I attempted to go back to 2.10.1 by building from source, and found that I couldn't, due to the foregoing configure error. I was then told I could resolve the x11() plotting problems by updating my OS. I finally got around to doing that --- just now --- and indeed this fixed the x11() plotting problems. I then figured I'd check and if it had also fixed the ``headers/libs are not available'' problem --- it hadn't. So can anyone tell me (preferably in monosyllables, i.e. please make it easy to understand) Install readline (library + headers) - it is explained in the FAQ. monosyllabic instructions: run curl -s http://r.research.att.com/libs/readline-5.2-12-darwin8-bin4.tar.gz | sudo tar fvxz - -C / The error you get means that you have some broken readline (or compatible) in your system. The only way to find out exactly is to look at config.log since it is specific to your particular setup (stock OS X does not have that problem AFAIK). Cheers, Simon how I can fix the ``headers/libs are not available'' problem? I.e. how do I make the ``headers/libs'' available? I ***would*** like to be able to build R from source, just as a fallback. Ta. cheers, Rolf Turner P. S. My OS is Mac OS X 10.6.3. The screen output from configure, just before the error, was: . . . checking for library containing dlopen... none required checking readline/history.h usability... yes checking readline/history.h presence... yes checking for readline/history.h... yes checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking for rl_callback_read_char in -lreadline... no checking for main in -lncurses... yes checking for rl_callback_read_char in -lreadline... no checking for history_truncate_file... no ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. This e-mail has been scanned and cleared by MailMarshal www.marshalsoftware.com ## ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problem with readline when building R from source.
Rolf, you have broken fink is /sw -- remove it (or move aside) and all should be well :) Cheers, S On May 20, 2010, at 9:27 PM, Rolf Turner wrote: On 21/05/2010, at 12:55 PM, Simon Urbanek wrote: On May 20, 2010, at 8:33 PM, Rolf Turner wrote: I (just now) attempted to build an older version of R (2.10.1) from source. The ./configure step came to a halt with an error: configure: error: --with-readline=yes (default) and headers/libs are not available In the past I had been able to build R from source with no problems. A short time ago, after installing R 2.11.0 (and having some problems with x11() plotting) I attempted to go back to 2.10.1 by building from source, and found that I couldn't, due to the foregoing configure error. I was then told I could resolve the x11() plotting problems by updating my OS. I finally got around to doing that --- just now --- and indeed this fixed the x11() plotting problems. I then figured I'd check and if it had also fixed the ``headers/libs are not available'' problem --- it hadn't. So can anyone tell me (preferably in monosyllables, i.e. please make it easy to understand) Install readline (library + headers) - it is explained in the FAQ. monosyllabic instructions: run curl -s http://r.research.att.com/libs/readline-5.2-12-darwin8-bin4.tar.gz | sudo tar fvxz - -C / The error you get means that you have some broken readline (or compatible) in your system. The only way to find out exactly is to look at config.log since it is specific to your particular setup (stock OS X does not have that problem AFAIK). Your instructions were certainly clear enough; even I was able to follow them. :-) However the impact of following these instructions was nil. The screen output following my execution of your recipe was: $ curl -s http://r.research.att.com/libs/readline-5.2-12-darwin8-bin4.tar.gz | sudo tar fvxz - -C / Password: usr/ usr/local/ usr/local/include/ usr/local/include/readline/ usr/local/include/readline/chardefs.h usr/local/include/readline/history.h usr/local/include/readline/keymaps.h usr/local/include/readline/readline.h usr/local/include/readline/rlconf.h usr/local/include/readline/rlstdc.h usr/local/include/readline/rltypedefs.h usr/local/include/readline/tilde.h usr/local/info/ usr/local/info/dir usr/local/info/history.info usr/local/info/readline.info usr/local/info/rluserman.info usr/local/lib/ usr/local/lib/libhistory.5.2.dylib usr/local/lib/libhistory.5.dylib usr/local/lib/libhistory.a usr/local/lib/libhistory.dylib usr/local/lib/libreadline.5.2.dylib usr/local/lib/libreadline.5.dylib usr/local/lib/libreadline.a usr/local/lib/libreadline.dylib usr/local/man/ usr/local/man/man3/ usr/local/man/man3/history.3 usr/local/man/man3/readline.3 But when I then tried the ./configure trick I got the same error message as before. Looking into config.log I found: . . . configure:21583: checking for readline/readline.h configure:21591: result: yes configure:21609: checking for rl_callback_read_char in -lreadline configure:21644: gcc -o conftest -g -O2 -I/sw/include -I/usr/local/include -L/sw/lib -L/usr/local/lib conftest.c -lreadline 5 ld: warning: in /sw/lib/libreadline.dylib, file was built for i386 which is not the architecture being linked (x86_64) Undefined symbols: _rl_callback_read_char, referenced from: _main in ccRxZQbm.o ld: symbol(s) not found collect2: ld returned 1 exit status configure:21650: $? = 1 . . . Can you suggest anything that I might do about this problem? Ta. cheers, Rolf ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. This e-mail has been scanned and cleared by MailMarshal www.marshalsoftware.com ## ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Advice on setting my options for the old q() for quitting the R GUI
Ian, On May 10, 2010, at 8:27 PM, Ian Dworkin wrote: Hi All As I just upgraded to a new macbook pro, I finally updated to R 2.11.0. I was hoping for a quick suggestion on how to set it so that I can utilize q() or quit() as I use to back in the good old days of 2.9.x !! As the message says, if you really want to do that and kill all your documents, you can either use base::q() or base::quit() directly or (as NEWS say) set RGUI.base.quit option to TRUE if you want the old (dangerous) behavior. Just as a reminder the only safe way to close the R GUI is CmdQ (followed by CmdD or Enter depending on whether you want to save the workspace or not) otherwise the GUI is killed instead of closed resulting in potential data loss. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Installing 2.11 while keeping previous version
On May 11, 2010, at 3:29 PM, Richard Friedman wrote: Dear List, I want to install R.2.11 for Mac while keeping my previous versions (R.2.9 is the most recent.). I am running Mac OS X 10.5.8. On the installer the following note appears: Note: By default the installer upgrades previous Leopard build of R if present. If you want to keep the previous Leopard build, use pkgutil --forget org.r-project.R.Leopard.fw.pkg Here is what happens when I try the command [richard-friedmans-computer:/usr/sbin] friedman% ./pkgutil --forget org.r-project.R.Leopard.fw.pkg No receipt for 'org.r-project.R.Leopard.fw.pkg' found at '/'. I means that you did not install any previous version of the R framework for Leopard so there is nothing to forget. If you want to make 100% sure that there are no other receipts, check your list of packages with something like pkgutil --pkgs | grep -i r-project In the past I used to remove R-Framework.pkg from Library/Receipts but I am not sure that this will work this time. OS X 10.5 and higher no longer use Library/Receipts for native (flat) packages - but they might for legacy packages so if your package is way old, check there. However, the currently distributed R is Leopard build and a flat package, so it should be irrelevant given the message above. Cheers, Simon Thanks and best wishes, Rich Richard A. Friedman, PhD Associate Research Scientist, Biomedical Informatics Shared Resource Herbert Irving Comprehensive Cancer Center (HICCC) Lecturer, Department of Biomedical Informatics (DBMI) Educational Coordinator, Center for Computational Biology and Bioinformatics (C2B2)/ National Center for Multiscale Analysis of Genomic Networks (MAGNet) Room 824 Irving Cancer Research Center Columbia University 1130 St. Nicholas Ave New York, NY 10032 (212)851-4765 (voice) fried...@cancercenter.columbia.edu http://cancercenter.columbia.edu/~friedman/ In Memoriam, Philip Klass ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Perplexed benchmark result from a new Macbook Pro Core i5
On May 8, 2010, at 2:53 PM, Gardar Johannesson wrote:
I was just replacing a Macbook Pro from 2008 (with a 2.2GHz Intel Core 2 Duo)
with a new Macbook Pro (with a 2.4GHz Intel Core i5). To get a rough idea
about the difference in R execution speed I ran a small test, with the output
shown below. In short:
1) The new Macbook Pro was ca 60% _slower_ at linear algebra (crossprod() and
solve())
2) The new Macbook Pro was ca 17% faster on a long for-loop
3) Linking against Goto2 versus vecLib improved the linear algebra results
slightly
Both test were done using the same 2.11.0 dmg image from CRAN.
Any thoughts on this?
What OS X versions are on the respective machines? The vecLib performance
varies greatly with their versions.
Any ideas how I can improve the performance results? What about compiling
from source?
Note that you are essentially just comparing the BLAS libraries on each
machine, R is practically not involved in this at all, so if you meant R in the
compiling from source then the answer is likely no (R speed is what you see
in the loops).
I don't have an i5 arounds, but comparing similar architectures (Penryn vs
Nehalem) gives a slight edge to Nehalem (3.8s @ 2.8GHz vs 3.4s @ 2.66Ghz on
solve(B)) but that is for a Xeon so the memory speed may be the edge
(everything on OS X 10.6.3).
Cheers,
Simon
Thanks,
Gardar Johannesson
###
## Results from new macbook pro (Core i5 @ 2.4Ghz)
set.seed(1)
A - matrix(rnorm(2000*2000),2000,2000)
system.time(B - crossprod(A))
user system elapsed
2.500 0.058 0.816
system.time(B - crossprod(A))
user system elapsed
2.502 0.050 0.814
system.time(solve(B))
user system elapsed
7.208 0.265 2.740
system.time(solve(B))
user system elapsed
7.121 0.264 2.666
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
2.964 0.602 3.528
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
3.040 0.732 3.732
sessionInfo()
R version 2.11.0 (2010-04-22)
i386-apple-darwin9.8.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.11.0
###
## Results from old macbook pro (Core 2 Duo @ 2.2GHz)
set.seed(1)
A - matrix(rnorm(2000*2000),2000,2000)
system.time(B - crossprod(A))
user system elapsed
1.429 0.073 0.800
system.time(B - crossprod(A))
user system elapsed
1.429 0.064 0.874
system.time(solve(B))
user system elapsed
4.532 0.285 2.860
system.time(solve(B))
user system elapsed
4.521 0.281 2.834
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
3.501 0.764 4.215
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
3.459 0.702 4.113
sessionInfo()
R version 2.11.0 (2010-04-22)
i386-apple-darwin9.8.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
###
## Results from new macbook pro (Core i5 @ 2.4Ghz)
## Linking against Goto2 BLAS (vs vecLib)
set.seed(1)
A - matrix(rnorm(2000*2000),2000,2000)
system.time(B - crossprod(A))
user system elapsed
2.348 0.124 0.635
system.time(B - crossprod(A))
user system elapsed
2.342 0.110 0.622
system.time(solve(B))
user system elapsed
6.634 0.327 2.158
system.time(solve(B))
user system elapsed
6.697 0.348 2.034
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
2.577 0.548 2.885
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
2.411 0.478 2.859
sessionInfo()
R version 2.11.0 (2010-04-22)
i386-apple-darwin9.8.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Perplexed benchmark result from a new Macbook Pro Core i5
On May 10, 2010, at 3:44 PM, Stefan Evert wrote:
Just a thought: Wouldn't it make more sense to compare the elapsed times,
which show that both machines are more or less equally fast (with a slide
edge for the newer i5)?
I suspect that there is a change in the way user time is reported, which
probably adds up running times of four hyperthreads running on two cores for
the i5 CPU vs. only two threads on two cores for the Core 2 Duo. If I'm not
mistaken about the i5 architecture, this is not surprising: there are 4
threads, but they have to share 2 cores and don't seem to be able to run the
FP instructions in parallel on a single core; so they're running at half
speed only.
Oh my - how could I miss that :) Stefan, you're right - the elapsed is indeed
shorter on the i5 so ATLAS simply spreads some part across threads without any
gain (unsurprising on such small tasks). I got thrown off by the fact that
Shark was not reporting other threads, byt that may be an issue in Shark...
Thanks for the benchmark, by the way. It's good to know I'm not missing out
on R performance with my good old 2008 MacBook Pro. :-)
Well, ever since the GHz race is over the performance of machines has not
increased (or even to the contrary) since it's hard to feed all cores for
common R tasks in practice and per-thread speed has gone down (see the old
Nehalem benchmarks thread - unfortunately it's still true).
Cheers,
Simon
On 8 May 2010, at 20:53, Gardar Johannesson wrote:
###
## Results from new macbook pro (Core i5 @ 2.4Ghz)
set.seed(1)
A - matrix(rnorm(2000*2000),2000,2000)
system.time(B - crossprod(A))
user system elapsed
2.500 0.058 0.816
system.time(B - crossprod(A))
user system elapsed
2.502 0.050 0.814
system.time(solve(B))
user system elapsed
7.208 0.265 2.740
system.time(solve(B))
user system elapsed
7.121 0.264 2.666
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
2.964 0.602 3.528
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
3.040 0.732 3.732
###
## Results from old macbook pro (Core 2 Duo @ 2.2GHz)
set.seed(1)
A - matrix(rnorm(2000*2000),2000,2000)
system.time(B - crossprod(A))
user system elapsed
1.429 0.073 0.800
system.time(B - crossprod(A))
user system elapsed
1.429 0.064 0.874
system.time(solve(B))
user system elapsed
4.532 0.285 2.860
system.time(solve(B))
user system elapsed
4.521 0.281 2.834
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
3.501 0.764 4.215
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
3.459 0.702 4.113
sessionInfo()
R version 2.11.0 (2010-04-22)
i386-apple-darwin9.8.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
###
## Results from new macbook pro (Core i5 @ 2.4Ghz)
## Linking against Goto2 BLAS (vs vecLib)
set.seed(1)
A - matrix(rnorm(2000*2000),2000,2000)
system.time(B - crossprod(A))
user system elapsed
2.348 0.124 0.635
system.time(B - crossprod(A))
user system elapsed
2.342 0.110 0.622
system.time(solve(B))
user system elapsed
6.634 0.327 2.158
system.time(solve(B))
user system elapsed
6.697 0.348 2.034
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
2.577 0.548 2.885
system.time({a - rep(1.0,100); for(i in 1:1e6) a - 1.0*a+0.0})
user system elapsed
2.411 0.478 2.859
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] The libpng12.0.dylib hoo-hah.
Rolf, please look at the archives - this has been discussed here[1] at length
and updating your OS (including the security updates) solves this.
Cheers,
Simon
[1] https://stat.ethz.ch/pipermail/r-sig-mac/2010-May/007363.html
On May 6, 2010, at 11:36 PM, Rolf Turner wrote:
Dear Ben,
Thanks for your email. I guess I'll try the OS upgrade as you suggested,
unless I get other suggestions in the near future. I fear and tremble at
thought however. Something is sure to go wrong (Murphy's Law being what
it is).
cheers,
Rolf
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Fwd: [R] extracting a matched string using regexpr Possible BUG
FWIW I don't think \d is a basic regexp so as I would expect the perl mode to
work and it does:
test2-aaa12345W
sub(.*(\\d{5}).*, \\1, test2,perl=TRUE)
[1] 12345
Yet I agree that if should either fail (i.e. return the unmodified string) or
return 12345.
Also note that the bug is locale-specific:
LANG=C R
test2-aaa12345W
sub(.*(\\d{5}).*, \\1, test2,perl=TRUE)
[1] 12345
sub(.*(\\d{5}).*, \\1, test2)
[1] 12345
Also note that this is not Mac-specific:
test2-aaa12345W
sub(.*(\\d{5}).*, \\1, test2)
[1] W
system(uname -sr)
Linux 2.6.32-trunk-amd64
Sys.getlocale(LC_CTYPE)
[1] en_US.UTF-8
Cheers,
Simon
On May 6, 2010, at 6:54 AM, David Winsemius wrote:
On May 6, 2010, at 2:21 AM, steven mosher wrote:
see below,
using a regex in sub() fails if the pattern is //d{5} and suceeds
if the pattern [0-9] {5} is used.. see the test cases below.
issue was not on windows machine and david and I had it on MAC.
Except we both were using \\d rather than //d.
I believe that Steve is using R 2.11.0 but I am still using R 2.10.1 (but
with the release of an Hmisc upgrade I will convert soon.)
--
David.
sessionInfo()
R version 2.10.1 RC (2009-12-09 r50695)
x86_64-apple-darwin9.8.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] tcltk stats graphics grDevices utils datasets methods base
other attached packages:
[1] gsubfn_0.5-2 proto_0.3-8zoo_1.6-3 SASxport_1.2.3 lattice_0.18-3
loaded via a namespace (and not attached):
[1] chron_2.3-35 grid_2.10.1 tools_2.10.1
r11
mac os 10.5
-- Forwarded message --
From: steven mosher mosherste...@gmail.com
Date: Wed, May 5, 2010 at 3:25 PM
Subject: Re: [R] extracting a matched string using regexpr
To: David Winsemius dwinsem...@comcast.net
Cc: Gabor Grothendieck ggrothendi...@gmail.com, r-help
r-h...@r-project.org
with a fresh restart
test-/trtrth88958/ththAbcdsef/thth67.8S/thth68.9\nW/thth26m/th
test
[1]
/trtrth88958/ththAbcdsef/thth67.8S/thth68.9\nW/thth26m/th
sub(.*(\\d{5}).*, \\1, test)
[1] /th
sub(.*([0-9]{5}).*, \\1, test)
[1] 88958
test2-aaa12345W
sub(.*(\\d{5}).*, \\1, test2)
[1] W
sub(.*(\\d{5}).*, \\1, test2)
[1] W
sub(.*([0-9]{5}).*, \\1, test2)
[1] 12345
Steve.
On Wed, May 5, 2010 at 3:20 PM, David Winsemius
dwinsem...@comcast.netwrote:
On May 5, 2010, at 5:35 PM, Gabor Grothendieck wrote:
Here are two ways to extract 5 digits.
In the first one \\1 refers to the portion matched between the
parentheses in the regular expression.
In the second one strapply is like apply where the object to be worked
on is the first argument (array for apply, string for strapply) the
second modifies it (which dimension for apply, regular expression for
strapply) and the last is a function which acts on each value
(typically each row or column for apply and each match for strapply).
In this case we use c as our function to just return all the results.
They are returned in a list with one component per string but here
test is just a single string so we get a list one long and we ask for
the contents of the first component using [[1]].
# 1 - sub
sub(.*(\\d{5}).*, \\1, test)
test
[1]
/trtrth88958/ththAbcdsef/thth67.8S/thth68.9\nW/thth26m/th
I get different results than I expected given that \\d should be
synonymous with [0-9]:
sub(.*([0-9]{5}).*, \\1, test)
[1] 88958
sub(.*(\\d{5}).*, \\1, test)
[1] /th
--
David.
# 2 - strapply - see http://gsubfn.googlecode.com
library(gsubfn)
strapply(test, \\d{5}, c)[[1]]
On Wed, May 5, 2010 at 5:13 PM, steven mosher mosherste...@gmail.com
wrote:
Given a text like
I want to be able to extract a matched regular expression from a piece of
text.
this apparently works, but is pretty ugly
# some html
test-/trtrth88958/ththAbcdsef/thth67.8S/thth68.9\nW/thth26m/th
# a pattern to extract 5 digits
pattern-[0-9]{5}
# regexpr returns a start point[1] and an attribute match.length
attr(,match.length)
# get the substring from the start point to the stop point.. where stop =
start +length-1
answer-substr(test,regexpr(pattern,test)[1],regexpr(pattern,test)[1]+attr(regexpr(pattern,test),match.length)-1)
answer
[1] 88958
I tried using sub(pattern, replacement, x ) with a regexp that captured
the
group. I'd found an example of this in the mails
but it didnt seem to work..
__
r-h...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
David Winsemius, MD
West Hartford, CT
[[alternative HTML version deleted]]
Re: [R-SIG-Mac] Fwd: [R] extracting a matched string using regexpr Possible BUG
On May 6, 2010, at 11:50 AM, David Winsemius wrote:
Two Q's:
A) Is this supposed to happen with perl-mode?:
test-/trtrth88958/ththAbcdsef/thth67.8S/thth68.9\nW/thth26m/th
sub(.*(\\d{5}).*, \\1, test, perl=TRUE)
[1] 88958\nW/thth26m/th
sub(.*([0-9]{5}).*, \\1, test, perl=TRUE)
[1] 88958\nW/thth26m/th
Nope - perl does take EOL into account so .* will be matched only to the end of
line. For your purposes you want to enable ?s option, so you probably meant:
sub((?s).*(\\d{5}).*, \\1, test, perl=TRUE)
[1] 88958
Looks to me that a period is being improperly recognized.
On May 6, 2010, at 11:28 AM, Simon Urbanek wrote:
FWIW I don't think \d is a basic regexp
B) With regard to the default (which I read to be extended rather than
basic) vs. perl-like, the Extended section of the regex documentation
contains:
Symbols \d, \s, \D and \S denote the digit and space classes and their
negations.
Yes, you're right - extended is the default.
Cheers,
Simon
so as I would expect the perl mode to work and it does:
test2-aaa12345W
sub(.*(\\d{5}).*, \\1, test2,perl=TRUE)
[1] 12345
Yet I agree that if should either fail (i.e. return the unmodified string)
or return 12345.
Also note that the bug is locale-specific:
LANG=C R
test2-aaa12345W
sub(.*(\\d{5}).*, \\1, test2,perl=TRUE)
[1] 12345
sub(.*(\\d{5}).*, \\1, test2)
[1] 12345
Also note that this is not Mac-specific:
test2-aaa12345W
sub(.*(\\d{5}).*, \\1, test2)
[1] W
system(uname -sr)
Linux 2.6.32-trunk-amd64
Sys.getlocale(LC_CTYPE)
[1] en_US.UTF-8
Cheers,
Simon
On May 6, 2010, at 6:54 AM, David Winsemius wrote:
On May 6, 2010, at 2:21 AM, steven mosher wrote:
see below,
using a regex in sub() fails if the pattern is //d{5} and suceeds
if the pattern [0-9] {5} is used.. see the test cases below.
issue was not on windows machine and david and I had it on MAC.
Except we both were using \\d rather than //d.
I believe that Steve is using R 2.11.0 but I am still using R 2.10.1 (but
with the release of an Hmisc upgrade I will convert soon.)
--
David.
sessionInfo()
R version 2.10.1 RC (2009-12-09 r50695)
x86_64-apple-darwin9.8.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] tcltk stats graphics grDevices utils datasets methods
base
other attached packages:
[1] gsubfn_0.5-2 proto_0.3-8zoo_1.6-3 SASxport_1.2.3
lattice_0.18-3
loaded via a namespace (and not attached):
[1] chron_2.3-35 grid_2.10.1 tools_2.10.1
r11
mac os 10.5
-- Forwarded message --
From: steven mosher mosherste...@gmail.com
Date: Wed, May 5, 2010 at 3:25 PM
Subject: Re: [R] extracting a matched string using regexpr
To: David Winsemius dwinsem...@comcast.net
Cc: Gabor Grothendieck ggrothendi...@gmail.com, r-help
r-h...@r-project.org
with a fresh restart
test-/trtrth88958/ththAbcdsef/thth67.8S/thth68.9\nW/thth26m/th
test
[1]
/trtrth88958/ththAbcdsef/thth67.8S/thth68.9\nW/thth26m/th
sub(.*(\\d{5}).*, \\1, test)
[1] /th
sub(.*([0-9]{5}).*, \\1, test)
[1] 88958
test2-aaa12345W
sub(.*(\\d{5}).*, \\1, test2)
[1] W
sub(.*(\\d{5}).*, \\1, test2)
[1] W
sub(.*([0-9]{5}).*, \\1, test2)
[1] 12345
Steve.
On Wed, May 5, 2010 at 3:20 PM, David Winsemius
dwinsem...@comcast.netwrote:
On May 5, 2010, at 5:35 PM, Gabor Grothendieck wrote:
Here are two ways to extract 5 digits.
In the first one \\1 refers to the portion matched between the
parentheses in the regular expression.
In the second one strapply is like apply where the object to be worked
on is the first argument (array for apply, string for strapply) the
second modifies it (which dimension for apply, regular expression for
strapply) and the last is a function which acts on each value
(typically each row or column for apply and each match for strapply).
In this case we use c as our function to just return all the results.
They are returned in a list with one component per string but here
test is just a single string so we get a list one long and we ask for
the contents of the first component using [[1]].
# 1 - sub
sub(.*(\\d{5}).*, \\1, test)
test
[1]
/trtrth88958/ththAbcdsef/thth67.8S/thth68.9\nW/thth26m/th
I get different results than I expected given that \\d should be
synonymous with [0-9]:
sub(.*([0-9]{5}).*, \\1, test)
[1] 88958
sub(.*(\\d{5}).*, \\1, test)
[1] /th
--
David.
# 2 - strapply - see http://gsubfn.googlecode.com
library(gsubfn)
strapply(test, \\d{5}, c)[[1]]
On Wed, May 5, 2010 at 5:13 PM, steven mosher mosherste...@gmail.com
wrote:
Given a text like
I want to be able to extract a matched regular expression from a piece
of
text.
this apparently works, but is pretty
Re: [R-SIG-Mac] R2.11 Rattle Co
Morgan, On May 4, 2010, at 3:12 AM, Morgan wrote: Dear fellow R and Mac users, I try to promote open source tools for practicals with my students, but I have some issues with the installation of Rattle (great GUI for data mining) on Mac OSX computers (10.6.3 | X11). I'm trying to install it since last week without any success. I need it up and running in a short future that's why I request your help. I followed the official installation procedure: http://datamining.togaware.com/survivor/Install_Macintosh.html Just as a side note - that is not a good idea - external docs are unfortunately very often wrong and/or out of date. Please consult canonical sources instead. 1) Download and install GTK+ (25MB) from: http://r.research.att.com/gtk2-framework.dmg That is the wrong download for R 2.11.0 as you would see on the canonical page: http://r.research.att.com/ 2) Download and install GGobi (5MB) from: http://www.ggobi.org/downloads/ggobi-2.1.8.dmg 3) Installed R2.11(latest) | gfortran 4.2.3 | tcltk-8.5.5-x11 + updated all packages 4) install.packages(rattle, dependencies=c(Depends, Suggests)) When loading Rattle, it asked for a newer GTK so I installed (on my initiative) GTK+ 2.18.5 framework I found at: http://R.research.att.com/libs/GTK_2.18.5-X11.pkg Alright now I can load Rattle but it doesn't work at all, it keeps returning errors of two different kinds: 1) Tue May 4 08:43:24 COMPUTER.unil.ch R[379] Error: CGContextSetFont: invalid context 0x0 Tue May 4 08:43:24 COMPUTER.unil.ch R[379] Error: CGContextSetFontSize: invalid context 0x0 ...The list is much longer but always concerns CGContext something AFAICT this is just benign error from rattle/RGtk2 - it's probably trying to draw something before the window is ready. The stack trace is attached in case the maintainers want to have a look. It does not affect the usability AFAICT. 2) ( R:2190): Gtk-WARNING **: Unable to find default local directory monitor type( R:2190): Gtk-WARNING **: Unable to find default local directory monitor type Again, this is merely a warning - GTK+ does produce spurious warnings quite regularly. This time I can't seem to be able to reproduce this one. Cheers, Simon --- Breakpoint 1, 0x7fff824f7557 in CGContextSetFont () (gdb) bt #0 0x7fff824f7557 in CGContextSetFont () #1 0x0001030ec313 in _cairo_quartz_font_scaled_glyph_init () #2 0x0001030c766d in _cairo_scaled_glyph_lookup () #3 0x0001030e36d4 in _cairo_xlib_surface_show_glyphs () #4 0x0001030cae99 in _cairo_surface_show_text_glyphs () #5 0x0001030b6555 in _cairo_gstate_show_text_glyphs () #6 0x0001030aeb56 in cairo_show_glyphs () #7 0x000103095941 in pango_cairo_renderer_show_text_glyphs () #8 0x000103095cef in pango_cairo_renderer_draw_glyphs () #9 0x00010319df2d in pango_renderer_draw_glyphs () #10 0x00010309476a in _pango_cairo_do_glyph_string () #11 0x00010319df2d in pango_renderer_draw_glyphs () #12 0x00010319e612 in pango_renderer_draw_layout_line () #13 0x00010319eab5 in pango_renderer_draw_layout () #14 0x0001015baef1 in gdk_draw_layout_with_colors () #15 0x0001015bb0d6 in gdk_draw_layout () #16 0x000102c20f41 in gtk_default_draw_layout () #17 0x000102b993f4 in gtk_label_expose () #18 0x000102ba886f in _gtk_marshal_BOOLEAN__BOXED () #19 0x0001032cf7af in g_closure_invoke () #20 0x0001032e54a4 in signal_emit_unlocked_R () #21 0x0001032e6ae5 in g_signal_emit_valist () #22 0x0001032e7234 in g_signal_emit () #23 0x000102cb179e in gtk_widget_event_internal () #24 0x000102b1ee3d in gtk_container_propagate_expose () #25 0x000102b1f9a8 in gtk_container_expose () #26 0x000102ba886f in _gtk_marshal_BOOLEAN__BOXED () #27 0x0001032cf7af in g_closure_invoke () #28 0x0001032e54a4 in signal_emit_unlocked_R () #29 0x0001032e6ae5 in g_signal_emit_valist () #30 0x0001032e7234 in g_signal_emit () #31 0x000102cb179e in gtk_widget_event_internal () #32 0x000102b1ee3d in gtk_container_propagate_expose () #33 0x000102aefceb in gtk_box_forall () #34 0x000102b1f9a8 in gtk_container_expose () #35 0x000102ba886f in _gtk_marshal_BOOLEAN__BOXED () #36 0x0001032cf7af in g_closure_invoke () #37 0x0001032e54a4 in signal_emit_unlocked_R () #38 0x0001032e6ae5 in g_signal_emit_valist () #39 0x0001032e7234 in g_signal_emit () #40 0x000102cb179e in gtk_widget_event_internal () #41 0x000102b1ee3d in gtk_container_propagate_expose () #42 0x000102b1f9a8 in gtk_container_expose () #43 0x000102af6531 in gtk_button_expose () #44 0x000102ba886f in _gtk_marshal_BOOLEAN__BOXED () #45 0x0001032cf7af in g_closure_invoke () #46 0x0001032e54a4 in signal_emit_unlocked_R () #47 0x0001032e6ae5 in g_signal_emit_valist () #48 0x0001032e7234 in g_signal_emit () #49 0x000102cb179e in gtk_widget_event_internal () #50
Re: [R-SIG-Mac] R2.11 Rattle Co
On May 4, 2010, at 11:55 AM, Morgan wrote: Hi, Thanks for your insight. I got the GTK warning when I try to perform an action with the Rattle GUI (v2.5.30), for example loading data. The problem is that this error obviously prevents the program to run. I found many users reporting this issue but no one seems to have a clue. You're certainly a very advanced user with some kind of custom install of R. As you can use rattle you should certainly have something I don't. I don't use rattle at all - hence I need a reproducible example with your report. Cheers, Simon Message d'origine De: simon.urba...@r-project.org Date: 04.05.2010 16:44 À: spont...@bluewin.ch Copie: r-sig-...@stat. math.ethz.ch Objet: Re: [R-SIG-Mac] R2.11 Rattle amp; Co Morgan, On May 4, 2010, at 3:12 AM, Morgan wrote: Dear fellow R and Mac users, I try to promote open source tools for practicals with my students, but I have some issues with the installation of Rattle (great GUI for data mining) on Mac OSX computers (10.6.3 | X11). I'm trying to install it since last week without any success. I need it up and running in a short future that's why I request your help. I followed the official installation procedure: http://datamining.togaware.com/survivor/Install_Macintosh.html Just as a side note - that is not a good idea - external docs are unfortunately very often wrong and/or out of date. Please consult canonical sources instead. 1) Download and install GTK+ (25MB) from: http://r.research.att.com/gtk2-framework.dmg That is the wrong download for R 2.11.0 as you would see on the canonical page: http://r.research.att.com/ 2) Download and install GGobi (5MB) from: http://www.ggobi.org/downloads/ggobi-2.1.8.dmg 3) Installed R2.11(latest) | gfortran 4.2.3 | tcltk-8.5.5-x11 + updated all packages 4) install.packages(rattle, dependencies=c(Depends, Suggests)) When loading Rattle, it asked for a newer GTK so I installed (on my initiative) GTK+ 2.18.5 framework I found at: http://R.research.att.com/libs/GTK_2.18.5-X11.pkg Alright now I can load Rattle but it doesn't work at all, it keeps returning errors of two different kinds: 1) Tue May 4 08:43:24 COMPUTER.unil.ch R[379] Error: CGContextSetFont: invalid context 0x0 Tue May 4 08:43:24 COMPUTER.unil.ch R[379] Error: CGContextSetFontSize: invalid context 0x0 ...The list is much longer but always concerns CGContext something AFAICT this is just benign error from rattle/RGtk2 - it's probably trying to draw something before the window is ready. The stack trace is attached in case the maintainers want to have a look. It does not affect the usability AFAICT. 2) ( R:2190): Gtk- WARNING **: Unable to find default local directory monitor type( R:2190): Gtk-WARNING **: Unable to find default local directory monitor type Again, this is merely a warning - GTK+ does produce spurious warnings quite regularly. This time I can't seem to be able to reproduce this one. Cheers, Simon --- Breakpoint 1, 0x7fff824f7557 in CGContextSetFont () (gdb) bt #0 0x7fff824f7557 in CGContextSetFont () #1 0x0001030ec313 in _cairo_quartz_font_scaled_glyph_init () #2 0x0001030c766d in _cairo_scaled_glyph_lookup () #3 0x0001030e36d4 in _cairo_xlib_surface_show_glyphs () #4 0x0001030cae99 in _cairo_surface_show_text_glyphs () #5 0x0001030b6555 in _cairo_gstate_show_text_glyphs () #6 0x0001030aeb56 in cairo_show_glyphs () #7 0x000103095941 in pango_cairo_renderer_show_text_glyphs () #8 0x000103095cef in pango_cairo_renderer_draw_glyphs () #9 0x00010319df2d in pango_renderer_draw_glyphs () #10 0x00010309476a in _pango_cairo_do_glyph_string () #11 0x00010319df2d in pango_renderer_draw_glyphs () #12 0x00010319e612 in pango_renderer_draw_layout_line () #13 0x00010319eab5 in pango_renderer_draw_layout () #14 0x0001015baef1 in gdk_draw_layout_with_colors () #15 0x0001015bb0d6 in gdk_draw_layout () #16 0x000102c20f41 in gtk_default_draw_layout () #17 0x000102b993f4 in gtk_label_expose () #18 0x000102ba886f in _gtk_marshal_BOOLEAN__BOXED () #19 0x0001032cf7af in g_closure_invoke () #20 0x0001032e54a4 in signal_emit_unlocked_R () #21 0x0001032e6ae5 in g_signal_emit_valist () #22 0x0001032e7234 in g_signal_emit () #23 0x000102cb179e in gtk_widget_event_internal () #24 0x000102b1ee3d in gtk_container_propagate_expose () #25 0x000102b1f9a8 in gtk_container_expose () #26 0x000102ba886f in _gtk_marshal_BOOLEAN__BOXED () #27 0x0001032cf7af in g_closure_invoke () #28 0x0001032e54a4 in signal_emit_unlocked_R () #29 0x0001032e6ae5 in g_signal_emit_valist () #30 0x0001032e7234 in g_signal_emit () #31 0x000102cb179e in gtk_widget_event_internal () #32 0x000102b1ee3d in
Re: [R-SIG-Mac] problems with X11 in R 2.11.0
I can only second Brian's response. The build machine is a completely clean Mac OS X 10.5.8 (up to date with all recent security updates) - I have not installed any custom X11 updates. I don't know why Seth has an outdated libpng in the X11 installation. Seth, please make sure your system is up to date. Given the date of the last update I would suspect that Software Update should resolve this issue (if that is the case it's nonetheless a little annoying that Apple's security update would break backward compatibility). Cheers, Simon On May 3, 2010, at 1:19 AM, Prof Brian Ripley wrote: Something is wrong with your system software. On my Leopard box: tystie% otool -L /Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so ... /usr/X11/lib/libpng12.0.dylib (compatibility version 42.0.0, current version 42.0.0) So your /usr/X11/lib/libpng12.0.dylib is different from mine (and from the CRAN build machine's). Your choices are - to resolve this (and it is not an R issue). I'd start by running the software updater - to build R from the sources against the software on your machine. On Sun, 2 May 2010, steven mosher wrote: I had the same Issue with 2.10.1. never got it resolved. I was hoping that 2.11 would fix it...alas On Thu, Apr 29, 2010 at 2:59 PM, Seth Schommer scschom...@gmail.com wrote: I installed R 2.11.0 today and immediately came across an issue I did not experience using version 2.10.1. For some reason, I can not use X11 in R. Here's a simple example: X11() Error in X11() : X11 module cannot be loaded In addition: Warning message: In X11() : unable to load shared library '/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so': dlopen(/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so, 6): Library not loaded: /usr/X11/lib/libpng12.0.dylib Referenced from: /Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so Reason: Incompatible library version: R_X11.so requires version 42.0.0 or later, but libpng12.0.dylib provides version 36.0.0 sessionInfo() R version 2.11.0 (2010-04-22) i386-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base I'm running Mac OS X 10.5.8. This error occurs when running R.app and while running R from the terminal. After experience this I reinstalled 2.10.1 and tried the same command and had no problems. Just to make sure, I installed 2.11.0 again, and sure enough, I got the same error. Is this a bug, or have I done something wrong? Thanks, Seth ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- 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-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] problems with X11 in R 2.11.0
On May 3, 2010, at 3:37 PM, steven mosher wrote: I have 10.5.8. I posted on this a while back. I also had version 36.. I believe for lippng. That's clear - but did you have your system up-to-date? Cheers, Simon On Mon, May 3, 2010 at 12:01 PM, Simon Urbanek simon.urba...@r-project.org wrote: I can only second Brian's response. The build machine is a completely clean Mac OS X 10.5.8 (up to date with all recent security updates) - I have not installed any custom X11 updates. I don't know why Seth has an outdated libpng in the X11 installation. Seth, please make sure your system is up to date. Given the date of the last update I would suspect that Software Update should resolve this issue (if that is the case it's nonetheless a little annoying that Apple's security update would break backward compatibility). Cheers, Simon On May 3, 2010, at 1:19 AM, Prof Brian Ripley wrote: Something is wrong with your system software. On my Leopard box: tystie% otool -L /Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so ... /usr/X11/lib/libpng12.0.dylib (compatibility version 42.0.0, current version 42.0.0) So your /usr/X11/lib/libpng12.0.dylib is different from mine (and from the CRAN build machine's). Your choices are - to resolve this (and it is not an R issue). I'd start by running the software updater - to build R from the sources against the software on your machine. On Sun, 2 May 2010, steven mosher wrote: I had the same Issue with 2.10.1. never got it resolved. I was hoping that 2.11 would fix it...alas On Thu, Apr 29, 2010 at 2:59 PM, Seth Schommer scschom...@gmail.com wrote: I installed R 2.11.0 today and immediately came across an issue I did not experience using version 2.10.1. For some reason, I can not use X11 in R. Here's a simple example: X11() Error in X11() : X11 module cannot be loaded In addition: Warning message: In X11() : unable to load shared library '/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so': dlopen(/Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so, 6): Library not loaded: /usr/X11/lib/libpng12.0.dylib Referenced from: /Library/Frameworks/R.framework/Resources/modules/i386/R_X11.so Reason: Incompatible library version: R_X11.so requires version 42.0.0 or later, but libpng12.0.dylib provides version 36.0.0 sessionInfo() R version 2.11.0 (2010-04-22) i386-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base I'm running Mac OS X 10.5.8. This error occurs when running R.app and while running R from the terminal. After experience this I reinstalled 2.10.1 and tried the same command and had no problems. Just to make sure, I installed 2.11.0 again, and sure enough, I got the same error. Is this a bug, or have I done something wrong? Thanks, Seth ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- 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-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] problems with X11 in R 2.11.0
On May 3, 2010, at 5:04 PM, David Winsemius wrote: On May 3, 2010, at 4:48 PM, Simon Urbanek wrote: On May 3, 2010, at 4:04 PM, David Winsemius wrote: On May 3, 2010, at 3:37 PM, steven mosher wrote: I have 10.5.8. I posted on this a while back. I also had version 36.. I believe for lippng. (Calling X11() did not really crash my machine. but it reported a serious error and asked me to save and restart. otools reports my version in that directory is 36.0.0. /usr/X11/lib/libpng12.0.dylib (compatibility version 36.0.0, current version 36.0.0) (Of course, it also lists about 10 other locations as well. Should I have posted the entire output? ) I install all updates when they are pushed. I just did a Software Update of my 10.5.8 machine and it says I am up-to-date. Hmm.. now the real question is why some Leopard systems have libpng12 version 36 and some have version 42. As I said the build machine has a pristine Leopard install, I did not install any custom X11 updates - it just has all security updates. pkginfo reveals that the file has been last updated by the 2010 Leopard security update 02: hagal:~$ pkgutil -v --file-info /usr/X11/lib/libpng12.0.dylib volume: / path: usr/X11/lib/libpng12.0.dylib [...] pkgid: com.apple.pkg.update.security.2010.002.leopard Thanks, Simon; Just a note before I hit the restart button ... the package that is current is Security Update 2010-003 and my log files show that I already installed it on 4/16/2010. The log files do not have an entry for Security Update 2010-002. (But 2010-003 does say it incorporates all previous updates.) With the 2010-02 update installed you should see: hagal:~$ ls -l /usr/X11/lib/libpng12.0.dylib -rwxr-xr-x 1 root wheel 684448 Dec 7 23:33 /usr/X11/lib/libpng12.0.dylib That matches the content of the update package: ginaz:su$ lsbom SecUpd2010-003.pkg/Bom |grep /libpng12.0.d ./usr/X11/lib/libpng12.0.dylib 100755 0/0 684448 3378515879 So the update should really solve the issue. FWIW the full output on the build machine: hagal:~$ ls -l /usr/X11/lib/libpng12*dylib lrwxr-xr-x 1 root wheel 16 Apr 13 13:40 /usr/X11/lib/libpng12.0.24.0.dylib - libpng12.0.dylib lrwxr-xr-x 1 root wheel 16 Apr 13 13:58 /usr/X11/lib/libpng12.0.35.0.dylib - libpng12.0.dylib lrwxr-xr-x 1 root wheel 16 Apr 13 14:18 /usr/X11/lib/libpng12.0.41.0.dylib - libpng12.0.dylib -rwxr-xr-x 1 root wheel 684448 Dec 7 23:33 /usr/X11/lib/libpng12.0.dylib lrwxr-xr-x 1 root wheel 16 Apr 13 13:40 /usr/X11/lib/libpng12.dylib - libpng12.0.dylib hagal:~$ otool -L /usr/X11/lib/libpng12.0.dylib /usr/X11/lib/libpng12.0.dylib: /usr/X11/lib/libpng12.0.dylib (compatibility version 42.0.0, current version 42.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) Cheers, Simon -- David. pkg-version: 1.0.1.1191932192 install-time: Tue Apr 13 14:18:52 2010 uid: 0 (root) gid: 0 (wheel) mode: 100755 (-rwxr-xr-x ) I would suggest installing the latest Leopard security upgrade by hand (if your Software Update really shows up-to-date system otherwise use System Update) - it also includes the 02 update which in turn includes the updated libpng: http://support.apple.com/kb/DL1027 (This is for Mac OS X 10.5.8 client [=not server] *ONLY*) Does it matter that I set a fairly long Sys.env path in my .Rprofile and that /usr/X11/lib is not in that path? No, it doesn't matter. Cheers, Simon Sys.setenv(PATH=/opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin) For the record, I am not having problems with R or RGL which I believe requires X11 for some of its display. And capabilities() thinks I have X11: capabilities() jpeg png tifftcltk X11 aqua http/ftp sockets libxml TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE fifo clediticonv NLS profmemcairo TRUE TRUE TRUE TRUE TRUE TRUE sessionInfo() R version 2.10.1 RC (2009-12-09 r50695) ### I don't really want to update to 2.11.0 because of the Hmisc incompatibility. I use Harrell's packages extensively. x86_64-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] lattice_0.18-3 loaded via a namespace (and not attached): [1] grid_2.10.1 tools_2.10.1 On Mon, May 3, 2010 at 12:01 PM, Simon Urbanek simon.urba...@r-project.orgwrote: I can only second Brian's response
Re: [R-SIG-Mac] R CMD check fails on Snow Leopard
On Apr 30, 2010, at 4:55 PM, cstrato wrote: Dear Simon, dear Kasper, While I could solve the problem with wrong architecture, R CMD check now results in the following error: installing to /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/x86_64 ** R ** inst ** preparing package for lazy loading ** help *** installing help indices ** building package indices ... ** testing if installed package can be loaded Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/x86_64/xps.so': dlopen(/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/x86_64/xps.so, 6): Symbol not found: __ZN10TCanvasImp11ShowMembersER16TMemberInspectorPc Referenced from: /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/x86_64/xps.so Expected in: flat namespace in /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/x86_64/xps.so ERROR: loading failed * removing '/Volumes/CoreData/CRAN/xps.Rcheck/xps' This time I get this error both on Leopard for i386 and on Snow Leopard for x86_64 while the Bioconductor server does not have this problem (to my great relieve), see: http://bioconductor.org/checkResults/2.6/bioc-LATEST/xps/pelham-checksrc.html Do you have any idea what might be the reason for this problem? Likely xps was not linked against all necessary libraries. Since it is sinked as dynamic library bugs like that are only visible at run-time not at link-time. Cheers, Simon On 4/29/10 5:25 AM, Kasper Daniel Hansen wrote: You can have a look at the library by doing file (otool is also nice to know btw), I get # file affxparser.so affxparser.so: Mach-O 64-bit dynamically linked shared library x86_64 You do this on both the ROOT library and the xps.so library to see what the architectures are. Based on the error message, they are different. Why, is something I think you will have to track down yourself, because that depends on how you compiled R/ROOT. Kasper On Wed, Apr 28, 2010 at 5:54 PM, cstratocstr...@aon.at wrote: Dear Simon, My package is xps which has always worked on Tiger and also on Leopard, thus I am shocked that it does not work on Snow Leopard. The problem is not only that I cannot do R32 CMD check xps-1.9.0.tar.gz which results in the error message mentioned, but that the binary which I have downloaded using biocLite(xps) gives me the same error message. When I start R32 which I need to do since I have compiled the ROOT framework for 32 bit, I get: library(xps) Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/Users/rabbitus/Library/R/2.11/library/xps/libs/i386/xps.so': dlopen(/Users/rabbitus/Library/R/2.11/library/xps/libs/i386/xps.so, 6): Library not loaded: @rpath/libCore.so Referenced from: /Users/rabbitus/Library/R/2.11/library/xps/libs/i386/xps.so Reason: no suitable image found. Did find: /Volumes/CoreData/ROOT/root/lib/libCore.so: mach-o, but wrong architecture /Volumes/CoreData/ROOT/root/lib/libCore.so: mach-o, but wrong architecture Error: package/namespace load failed for 'xps' At the moment I have no idea what might be the reason for this:-( Best regards Christian On 4/28/10 11:38 PM, Simon Urbanek wrote: On Apr 28, 2010, at 5:22 PM, cstrato wrote: Dear all, Last week I have installed on my MacBook Pro Snow Leopard 10.6.3 and downloaded from Apple Xcode 3.2.2. Then I have installed R-2.11.0.pkg for Mac OS X 10.5 (Leopard) and higher. Now I wanted to run R CMD check for my BioC package which contains C++ code but got the following error: installing to /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386 ** R ** inst ** preparing package for lazy loading ** help *** installing help indices ** building package indices ... ** testing if installed package can be loaded Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386/xps.so': dlopen(/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386/xps.so, 6): no suitable image found. Did find: /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386/xps.so: mach-o, but wrong architecture ERROR: loading failed * removing '/Volumes/CoreData/CRAN/xps.Rcheck/xps' Do you have any hint what might be the reason for this error? Apparently the R and your package have different architectures. The reason is most likely your package - often badly written Makevars or Makefile if some dependencies are used, or stale object files in the sources (failure to clean up) etc. You'd have to show us the package and exactly how you're trying to instal it if we are to help you further. As far as I understand this message means that Snow Leopard is the wrong architecture, why? You understand the message incorrectly - it tells you the R (which is the one loading the package) cannot find binary of the same architecture in the package, but it can find another, different
Re: [R-SIG-Mac] any advice on libtiff? (and rtiff)
On Apr 29, 2010, at 10:39 AM, c...@witthoft.com wrote: OK, I've got libtiff installed -- the libraries are sitting in /usr/local/lib . Do I need to copy them somewhere else for R to be able to find them? Or (I'm trying this under OS X 10.4.11, i686-apple-darwin8-gcc-4.0.1 ) do I have incompatible support tools? Likely the latter - your Xcode is too old. Current Xcode for 10.4 is Xcode 2.5 and the last releases of R for 10.4 required at least Xcode 2.4.1. Cheers, Simon Thanks for your help Here's the error message I get after %R CMD INSTALL rtiff : * installing to library '/Library/Frameworks/R.framework/Resources/library' * installing *source* package 'rtiff' ... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for TIFFOpen in -ltiff... yes configure: creating ./config.status config.status: creating src/Makevars ** libs ** arch - i386 gcc -arch i386 -std=gnu99 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -I/usr/local/include-fPIC -g -O2 -c rtiff.c -o rtiff.o gcc -arch i386 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names -mmacosx-version-min=10.4 -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -o rtiff.so rtiff.o -ltiff -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation /usr/bin/libtool: for architecture cputype (16777223) cpusubtype (3) object: /usr/local/lib/libgcc_s.10.4.dylib malformed object (unknown load command 4) make: *** [rtiff.so] Error 1 ERROR: compilation failed for package 'rtiff' * removing '/Library/Frameworks/R.framework/Resources/library/rtiff' Apr 29, 2010 01:52:21 AM, rip...@stats.ox.ac.uk wrote: === On Wed, 28 Apr 2010, Carl Witthoft wrote: Hi, I know rtiff does not compile 'cause it can't find libtiff (per cran check logs). I'm just wondering if anyone has successfully installed libtiff, either from source or via MacPorts? And if so, is it then possible to build rtiff from the source and have everything work? Yes, yes. Simon and I have (separately) installed libtiff from the sources and the static-library build is what is used for the CRAN R distribution (at my behest). When I tried rtiff it simply worked: tystie% R CMD INSTALL rtiff_1.4.1.tar.gz * installing to library ‘/Users/ripley/R/Library’ * installing *source* package ‘rtiff’ ... checking for gcc... gcc ... ** testing if installed package can be loaded * DONE (rtiff) One arch only, as the package has a configure script. Add others with e.g. tystie% R --arch=x86_64 CMD INSTALL --libs-only rtiff_1.4.1.tar.gz So far I've (naively) tried building libtiff3.9.2 from sources, but even though make seems to happily complete its job, nothing seems to be installed anywhere useful. Well, the latter is what 'make install' does, just like just about all other Open Source packages. But see http://r.research.att.com/libs/ for Simon's build. Or should I just bite the bullet and install the Gtk tiff tools and that big graphics package (something-BE, I forget the name just now)? thanks Carl -- 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-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] any advice on libtiff? (and rtiff)
On Apr 28, 2010, at 6:25 PM, Carl Witthoft wrote:
Hi, I know rtiff does not compile 'cause it can't find libtiff (per cran
check logs).
Unfortunately rtiff forces wrong flags (that it checks with the wrong compilers
and flags) and it allows no way around it so the best way forward would be if
Eric could address this (details below).
The correct flags for the static build are PKG_LIBS=-ltiff -ljpeg -lz because
libtiff relies on JPEG and libz, but rtiff does not allow that.
I'm CCing Eric in the hope that this can be addressed in the package:
First, configure will check with CPPFLAGS, CFLAGS, LIBS etc. yet those all are
ignored since there is
PKG_LIBS=-ltiff
which is wrong - that's not what configure actually checked at all.
AC_CHECK_LIB modifies LIBS to reflect the correct flags so it should be at the
very least
PKG_LIBS=$LIBS
Second, the R compiler settings are ignored so the checks are actually run with
the wrong compiler (this is crucial because let's say if you compile for
R_ARCH=/x86_64 then the checks will be run with the default architecture of the
compiler such as i386 which is completely different).
Also to make it more R friendly it is a good idea to initialize
LIBS=$PKG_LIBS so that the commonly used PKG_LIBS are respected (this is
optional). So the configure.in could look something like
AC_PREREQ(2.1)
AC_INIT([rtiff], [1.1], [eric.k...@vai.org])
AC_CONFIG_SRCDIR([src/rtiff.c])
: ${R_HOME=`R RHOME`}
if test -z ${R_HOME}; then
echo could not determine R_HOME
exit 1
fi
RBIN=${R_HOME}/bin/R
CC=`${RBIN} CMD config CC`;
CFLAGS=`${RBIN} CMD config CFLAGS`
LIBS=${PKG_LIBS}
# Checks for programs.
AC_PROG_CC
# Checks for libtiff.
AC_CHECK_LIB([tiff], [TIFFOpen], [], [
echo Error: Could not find libtiff.
exit -1
])
PKG_LIBS=$LIBS
AC_SUBST(PKG_LIBS)
AC_OUTPUT([src/Makevars])
Thanks,
Simon
I'm just wondering if anyone has successfully installed libtiff, either from
source or via MacPorts? And if so, is it then possible to build rtiff from
the source and have everything work?
So far I've (naively) tried building libtiff3.9.2 from sources, but even
though make seems to happily complete its job, nothing seems to be
installed anywhere useful.
Or should I just bite the bullet and install the Gtk tiff tools and that big
graphics package (something-BE, I forget the name just now)?
thanks
Carl
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] OSX gFortran
Mike, On Apr 29, 2010, at 2:47 PM, Mike Arthur wrote: Hi guys, Thanks for your great work on the gfortran version for OSX from these sites: http://r.research.att.com/tools/ http://cran.r-project.org/bin/macosx/tools/ I'm doing some work for the Mac Homebrew package manager and I'm wanting to try and allow the building of gfortran. Could you advise me on who built the binaries on the above sites and give me their contact details? I am building all Mac gfortran binaries. The detailed instructions are on the same page where you got the fortran from: http://r.research.att.com/tools/ The Xcode builds are using Apple's Xcode sources + libfortran + gcc/fortran from gcc-4.2.4 sources + diff is on the tools page. The build is done the same way Apple Xcode is compiled. The alternative GNU build is done from the GNU release sources and is described on the page as well. I'd really like to try and have reproducible build instructions to build a formula for Homebrew so our users can have gfortran. I'd love to know where you get your sources from (I presume here: http://www.opensource.apple.com/) and what patches and configure lines you use to build the binaries? Thanks already for your work and I'm sorry to intrude on this mailing list! Sure, not problem. Please feel free to contact me if you have any questions. (I think I was talking to Max a while ago about improvements to Homebrew ;) - I like the idea) Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] R CMD check fails on Snow Leopard
On Apr 28, 2010, at 5:22 PM, cstrato wrote: Dear all, Last week I have installed on my MacBook Pro Snow Leopard 10.6.3 and downloaded from Apple Xcode 3.2.2. Then I have installed R-2.11.0.pkg for Mac OS X 10.5 (Leopard) and higher. Now I wanted to run R CMD check for my BioC package which contains C++ code but got the following error: installing to /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386 ** R ** inst ** preparing package for lazy loading ** help *** installing help indices ** building package indices ... ** testing if installed package can be loaded Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386/xps.so': dlopen(/Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386/xps.so, 6): no suitable image found. Did find: /Volumes/CoreData/CRAN/xps.Rcheck/xps/libs/i386/xps.so: mach-o, but wrong architecture ERROR: loading failed * removing '/Volumes/CoreData/CRAN/xps.Rcheck/xps' Do you have any hint what might be the reason for this error? Apparently the R and your package have different architectures. The reason is most likely your package - often badly written Makevars or Makefile if some dependencies are used, or stale object files in the sources (failure to clean up) etc. You'd have to show us the package and exactly how you're trying to instal it if we are to help you further. As far as I understand this message means that Snow Leopard is the wrong architecture, why? You understand the message incorrectly - it tells you the R (which is the one loading the package) cannot find binary of the same architecture in the package, but it can find another, different, architecture instead. Snow Leopard is not an architecture it's an operating system. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Which Fortran Compiler is usable
On Apr 28, 2010, at 4:26 PM, Yan Zhou wrote: I have a some sort silly question. Which fortran compiler is usable with R, e.g., building package from source. I intended to install the gfortran from CRAN. But noticed that it will install cc1 and the text in installer stated that it is not recommended to install it with Xcode later than 3.2. I have 3.2.2 installed right now. Apple has not released Xcode 3.2.2 sources yet so we cannot build the corresponding version. What you can do (if you want) is to save the cc1 from Xcode and install the Fortran anyway. That said, you don't have to. You can equally well use the separate Fortran from CRAN http://cran.us.r-project.org/bin/macosx/tools/ if you want. (It's not how we build R anymore but it also works - at least with R 2.11.0) Besides I find on the website that gfortran from HPC will not work. So my question is that, what is the problem with the HPC version of gfortran. What is the criteria for a fortran compiler to be usable with R. It must support Apple driver's driver (for things like -arch ppc -arch i386 etc.) and have the corresponding cross-compilers included so you can build universal binaries. The HPC fortran is typically a single-host same-target compiler so it won't be able to do that (and has no Apple driver). In addition HPC compilers used to be a mess - they mostly didn't work at all due to library issues and cross-OS pollution, but I didn't test them lately, so may be things have improved in the meantime. I have intel fortran compiler installed. I managed to use it to compile a usable R-devel build from source. However, successful compiling doesn't imply that the generated code has no problem. If you build R from scratch from sources, there is no issue - you can use almost anything. What we are talking about is CRAN R binary - and by definition you can only use compilers that are compatible to the compilers used to compile that binary. That's what the recommended compilers are about. If you build your own R, you can use whatever flags you wish, so you can get different compilers to work -- but you won't be able to install package binaries from CRAN (in general). I hope it helps. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Which Fortran Compiler is usable
On Apr 28, 2010, at 5:47 PM, Yan Zhou wrote: Thank you for clarify all this for me. If I understand correctly. I can build R from scratch with any compilers support required language features (like F95 or partial C99). And use those compilers to install packages from source. In this way I can take any advantaged may provid by those compilers or library like MKL. However, if I want to use the distributed binary version of R, I have to use the same compiler configuration to build package or use the binary version package distributed from CRAN. Hope I get the right idea. Yes, exactly. (Just FWIW regarding MKL: our binary uses vecLib/Accelerate which is quite well optimized by Apple and was the most efficient one when I tested it against MKL and others). Cheers, Simon On 28 Apr 2010, at 22:39, Simon Urbanek wrote: On Apr 28, 2010, at 4:26 PM, Yan Zhou wrote: I have a some sort silly question. Which fortran compiler is usable with R, e.g., building package from source. I intended to install the gfortran from CRAN. But noticed that it will install cc1 and the text in installer stated that it is not recommended to install it with Xcode later than 3.2. I have 3.2.2 installed right now. Apple has not released Xcode 3.2.2 sources yet so we cannot build the corresponding version. What you can do (if you want) is to save the cc1 from Xcode and install the Fortran anyway. That said, you don't have to. You can equally well use the separate Fortran from CRAN http://cran.us.r-project.org/bin/macosx/tools/ if you want. (It's not how we build R anymore but it also works - at least with R 2.11.0) Besides I find on the website that gfortran from HPC will not work. So my question is that, what is the problem with the HPC version of gfortran. What is the criteria for a fortran compiler to be usable with R. It must support Apple driver's driver (for things like -arch ppc -arch i386 etc.) and have the corresponding cross-compilers included so you can build universal binaries. The HPC fortran is typically a single-host same-target compiler so it won't be able to do that (and has no Apple driver). In addition HPC compilers used to be a mess - they mostly didn't work at all due to library issues and cross-OS pollution, but I didn't test them lately, so may be things have improved in the meantime. I have intel fortran compiler installed. I managed to use it to compile a usable R-devel build from source. However, successful compiling doesn't imply that the generated code has no problem. If you build R from scratch from sources, there is no issue - you can use almost anything. What we are talking about is CRAN R binary - and by definition you can only use compilers that are compatible to the compilers used to compile that binary. That's what the recommended compilers are about. If you build your own R, you can use whatever flags you wish, so you can get different compilers to work -- but you won't be able to install package binaries from CRAN (in general). I hope it helps. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] gfortran bug?
Andreas,
I can't even get your code to compile - can you send the actual files, please?
Also you may want to ask on R-devel since I'm not sure there are many Fortran
specialists reading this mailing list... (Although there is a possibility of
miscompilations in majority the cases the cause is user code. The fact that it
works on another platform is not necessarily a proof that it is not a bug in
the code - it is often a coincidence).
Cheers,
Simon
PS: GNU Fortran 4.2.4 is really 4.2.4 - even if it is used in gcc 4.2.1 Xcode -
that's what you see on the command line.
On Apr 27, 2010, at 8:42 AM, Andreas Noack Jensen wrote:
I have been able to make an example that shows the weird behaviour. For the
Fortran code in last post run
rmfilter- function(x, coef)
{
dyn.load('~/rmfilter.so')
nl- dim(x)
cdim- dim(coef)
init- matrix(0, cdim[3], nl[2])
ans- .Fortran('rmfilter', as.double(x), as.integer(nl),
as.double(coef), as.integer(cdim), as.double(init))[[1]]
dim(ans)- dim(x)
return(ans)
}
eps - matrix(rnorm(300), ncol = 3)
tmp - lapply(seq(5000), function(x) rmfilter(eps, array(diag(3)*0.5,
c(3,3,2
sum(!sapply(2:5000, function(x) all.equal(tmp[[1]], tmp[[x]])) == 'TRUE')
The three last runs I have done give
tmp - lapply(seq(5000), function(x) rmfilter(eps, array(diag(3)*0.5,
c(3,3,2
sum(!sapply(2:5000, function(x) all.equal(tmp[[1]], tmp[[x]])) == 'TRUE')
[1] 639
tmp - lapply(seq(5000), function(x) rmfilter(eps, array(diag(3)*0.5,
c(3,3,2
sum(!sapply(2:5000, function(x) all.equal(tmp[[1]], tmp[[x]])) == 'TRUE')
[1] 0
tmp - lapply(seq(5000), function(x) rmfilter(eps, array(diag(3)*0.5,
c(3,3,2
sum(!sapply(2:5000, function(x) all.equal(tmp[[1]], tmp[[x]])) == 'TRUE')
[1] 29
I hope you have some ideas.
Best
Andreas
Den 25/04/10 16.22 skrev Andreas Noack Jensen
andreas.noack.jen...@econ.ku.dk følgende:
Dear list members
I have organised some code in a package including a Fortran subroutine for a
multivariate recursive filter to simulate VAR-porcesses. I have worked with
R for some time, but I am new to writing packages and coding Fortran so
first I thought I had made some mistakes in the Fortran code but I have now
tested the package on Ubuntu 10.4 and Windows XP and the problem is only
present on Mac.
On Mac I quite randomly get very weird results from the subroutine. It is
like the initial values explodes to fx 2e+290 even for identical calls
without random number generation. Most results are identical to results I
get from a pure R code but at some calls they explode in a non systematic
fashion.
I would have tried to use the gfortran 4.2.4 from r.research.att.com, to
isolate the error (right now I use their 4.2.3), but it seems like it
installs 4.2.1 instead and I get the same error still. I have tried to build
gfortran myself but was unsuccessful in doing so.
I cannot produce a small example you can run but as an example watch this:
for(i in 1:500){
+ cat(i)
+ tmp - I1(civecm:::simulate.I1(fit.postWW2, res =
fit.postWW2$residuals), 2, 'drift')
+ }
1234567891011121314Error in svd(X) : infinite or missing values in 'x'
for(i in 1:500){
+ cat(i)
+ tmp - I1(civecm:::simulate.I1(fit.postWW2, res =
fit.postWW2$residuals), 2, 'drift')
+ }
1234Error in svd(X) : infinite or missing values in 'x'
which is weird because there is no random number generation in play.
Completely identical calls every time. The error comes from the weird data
generated in the Fortran subroutine.
Some information about my system:
R version 2.11.0 (2010-04-22)
x86_64-apple-darwin9.8.0
locale:
[1] da_DK.UTF-8/da_DK.UTF-8/C/C/da_DK.UTF-8/da_DK.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] civecm_0.1-1 timsac_1.2.1 MASS_7.3-5 foreign_0.8-40
I use the latest prebuild version of R from r.research.att.com.
Finally the Fortran and R code for the subroute is:
subroutine rmfilter(x, nl, coef, ndim, init)
implicit none
integer, intent(in) :: nl(2), ndim(3)
double precision, intent(inout) :: x(nl(1),nl(2))
double precision, intent(in) :: coef(ndim(1),ndim(2),ndim(3)),
init(ndim(3),ndim(nl(2)))
double precision :: y(nl(1),nl(2))
integer :: i, j
y = 0.0d+0
do i = 1, nl(1), 1
do j = 1, ndim(3), 1
if ( i = j ) then
call dgemm('N', 'T', 1, ndim(1), nl(2), 1.0d+0,
init(ndim(3)-j+1,:), 1, coef(:,:,j), ndim(1), 1.0d+0, y(i,:), 1)
else
call dgemm('N', 'T', 1, ndim(1), nl(2), 1.0d+0, y(i-j,:), 1,
coef(:,:,j), ndim(1), 1.0d+0, y(i,:), 1)
end if
end do
y(i,:) = y(i,:) + x(i,:)
end do
x = y
return
end subroutine rmfilter
and
rmfilter- function(x, coef, init)
{
if(any(is.na(x))) stop('Series includes
Re: [R-SIG-Mac] Which gfortran for Snow Leopard?
On Apr 25, 2010, at 2:57 PM, cstrato wrote: Dear Simon, Since R-2.11.0 does no longer support Tiger I have just installed on my MacBook Pro Snow Leopard 10.6.3 and downloaded from Apple Xcode 3.2.2. Since there is still no gfortran I have installed your gfortran-42-5646.pkg. Now I wanted to compile ROOT for my BioC package xps and got the following error: g++ -dynamiclib -single_module -undefined dynamic_lookup -install_name @rpath/libminicern.so -O2 -o lib/libminicern.so misc/minicern/src/cernlib.o -ldl misc/minicern/src/hbook.o misc/minicern/src/kernlib.o misc/minicern/src/zebra.o libgfortran.dylib /usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64/libgfortranbegin.a i686-apple-darwin10-g++-4.2.1: libgfortran.dylib: No such file or directory If this sounds familiar to you, you remember correctly, see: https://stat.ethz.ch/pipermail/r-sig-mac/2010-January/007048.html Thus my obvious questions are: Is there a problem with gfortran-42-5646.pkg? Not really. Which gfortran should I use for Xcode 3.2.2? Apple has not released sources for Xcode 3.2.2 so there is no Fortran (if you're picky). Cheers, Simon Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ [[alternative HTML version deleted]] Please do respect the posting guide - you are ignoring it quite stubbornly and it's starting to have an effect on the answers you get. ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Which gfortran for Snow Leopard?
On Apr 26, 2010, at 12:59 PM, cstrato wrote: Dear Simon, Sadly, this time your answer is not really helpful for me. The helpfulness of an answer depends directly on the question asked. That's why it is really pays off to think before posting and make yourself clear on what you really want. I have checked after installing gfortran-42-5646.pkg whether there is a libgfortran.dylib file and could not find one. Are dylib files no longer necessary for Snow Leopard? No - they never were. Looking once again at http://r.research.att.com/tools/ I just realized that there is a dynamic libgfortran: libgfortran-4.2.4-5646.tar.gz. Since I have already installed gfortran-42-5646.pkg can I simply install the tar file, too, or do I need to deinstall the pkg file first? If you need dynamic gfortran library for some particular reason you can use that tar ball - it contains just the gfortran library (as the name implies). And as the accompanying text says you better know what the implications are. Cheers, Simon On 4/26/10 4:57 PM, Simon Urbanek wrote: On Apr 25, 2010, at 2:57 PM, cstrato wrote: Dear Simon, Since R-2.11.0 does no longer support Tiger I have just installed on my MacBook Pro Snow Leopard 10.6.3 and downloaded from Apple Xcode 3.2.2. Since there is still no gfortran I have installed your gfortran-42-5646.pkg. Now I wanted to compile ROOT for my BioC package xps and got the following error: g++ -dynamiclib -single_module -undefined dynamic_lookup -install_name @rpath/libminicern.so -O2 -o lib/libminicern.so misc/minicern/src/cernlib.o -ldl misc/minicern/src/hbook.o misc/minicern/src/kernlib.o misc/minicern/src/zebra.o libgfortran.dylib /usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64/libgfortranbegin.a i686-apple-darwin10-g++-4.2.1: libgfortran.dylib: No such file or directory If this sounds familiar to you, you remember correctly, see: https://stat.ethz.ch/pipermail/r-sig-mac/2010-January/007048.html Thus my obvious questions are: Is there a problem with gfortran-42-5646.pkg? Not really. Which gfortran should I use for Xcode 3.2.2? Apple has not released sources for Xcode 3.2.2 so there is no Fortran (if you're picky). Cheers, Simon Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l:cstrato at aon.at _._._._._._._._._._._._._._._._._._ [[alternative HTML version deleted]] Please do respect the posting guide - you are ignoring it quite stubbornly and it's starting to have an effect on the answers you get. ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] R.app on CommandQ asks but does not save
Thanks, Loren, that is a rather grave oversight in the R.app GUI, indeed. It is fixed now and I'll probably create an updated R installer package tomorrow since the bug has a rather nasty result. Thanks, Simon On Apr 26, 2010, at 6:43 PM, Loren Engrav wrote: sessionInfo() R version 2.11.0 (2010-04-22) x86_64-apple-darwin9.8.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base [R.app GUI 1.32 (5573) x86_64-apple-darwin9.8.0] I installed 2.11 and all went well But now on Command-Q then choosing Save, it just quits, no save Did my install go bad? [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Permanently change default console font
On Apr 23, 2010, at 9:59 PM, Mike Lawrence wrote: I tried poking at the source code again and I guess I didn't try hard enough the first time because this time I found that changing the default font is trivial: In files RConsoleController.m RController.m, change all instances of NSFont userFixedPitchFontOfSize:currentFontSize to NSFont fontWithName:@Menlo-Regular size:currentFontSize If you want to mess with the sources it's much easier - just add [NSFont setUserFixedPitchFont: [NSFont fontWithName:@Menlo-Regular size:12]]; anywhere in the startup - you don't need to change the font retrieval at all since it is already defined such that it gets your current default font. Cheers, Simon Mike On Fri, Apr 23, 2010 at 9:11 PM, Mike Lawrence mike.lawre...@dal.ca wrote: Hi Simon, Thanks for the reply. Indeed, I had already noticed in the source that the app was simply asking the system for its default fixed width font. I've searched for how to change this default but come up with nothing (searched system preferences, fontbook, google, etc). Any suggestions? Mike On Fri, Apr 23, 2010 at 9:00 PM, Simon Urbanek simon.urba...@r-project.org wrote: On Apr 23, 2010, at 4:24 PM, Mike Lawrence wrote: Hi folks, Sorry if this has been asked already, but I couldn't find any references to it in the list archives. Is there any way to change the default font of the mac GUI? If I open the app I can change the size of the font and this change persists even if I close and re-open the app, but changes in the font itself do not persist. I've played around with the source code, but can't seem to find what I'd need to modify to set a new default font (14pt Menlo, for example). Currently there is no way to change the font family - it is always left to the system to specify the font, GUI is just asking for fixed-width font. It is the default font for a given user so in theory by changing the default fixed width font for your account you will also change it in the GUI. You could add it to the wish list, though. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- Mike Lawrence Graduate Student Department of Psychology Dalhousie University Looking to arrange a meeting? Check my public calendar: http://tr.im/mikes_public_calendar ~ Certainty is folly... I think. ~ -- Mike Lawrence Graduate Student Department of Psychology Dalhousie University Looking to arrange a meeting? Check my public calendar: http://tr.im/mikes_public_calendar ~ Certainty is folly... I think. ~ ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Permanently change default console font
On Apr 23, 2010, at 4:24 PM, Mike Lawrence wrote: Hi folks, Sorry if this has been asked already, but I couldn't find any references to it in the list archives. Is there any way to change the default font of the mac GUI? If I open the app I can change the size of the font and this change persists even if I close and re-open the app, but changes in the font itself do not persist. I've played around with the source code, but can't seem to find what I'd need to modify to set a new default font (14pt Menlo, for example). Currently there is no way to change the font family - it is always left to the system to specify the font, GUI is just asking for fixed-width font. It is the default font for a given user so in theory by changing the default fixed width font for your account you will also change it in the GUI. You could add it to the wish list, though. Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Problems with read.xls on Mac OS X 10.6.3
Erich,
On Apr 22, 2010, at 11:43 AM, Erich Studerus wrote:
Hello
I'm trying to read an Excel-File with the read.xls function from gdata
(Version 2.7.1) on Mac with OS X 10.6.3, but get the following error message:
Can't load
'/Users/.../Library/R/2.10/library/gdata/perl/darwin-thread-multi-2level/auto/Compress/Raw/Zlib/Zlib.bundle'
for module Compress::Raw::Zlib:
/Users/.../Library/R/2.10/library/gdata/perl/darwin-thread-multi-2level/auto/Compress/Raw/Zlib/Zlib.bundle:
no appropriate 64-bit architecture (see man perl for running in 32-bit
mode) at /System/Library/Perl/5.10.0/darwin-thread-multi-2level/DynaLoader.pm
line 207.
at /Users/.../Library/R/2.10/library/gdata/perl/Archive/Zip.pm line 12
Compilation failed in require at
/Users/.../Library/R/2.10/library/gdata/perl/Archive/Zip.pm line 12.
I did not have this problem on a Mac with OX X 10.5.8. It seems that perl
must be running in 32bit mode, but is running in 64bit mode by default on my
system. The same problem has been discussed on R mailing list, but nobody has
provided a solution as far as I can see:
http://r.789695.n4.nabble.com/gdata-td1477079.html
Yes, there is a fundamental problem - gdata compiles a Perl module which is
incompatible across systems since each system has different version of Perl.
Currently the only safe solution is to install gdata from sources on OS X 10.6:
install.packages('gdata', type='source')
However, you'll need to install Xcode (shipped on the Snow Leopard DVD) before
you do the above.
gdata would need to be modified in order to fix the problem (or not embed perl
modules into the package).
Cheers,
Simon
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Failed tar extract
On Apr 19, 2010, at 10:42 PM, Steven McKinney wrote: After nuking /Library/Frameworks/R.framework and installing the CRAN version the same devpack error messages are produced. Since I often have to install packages from source, I'd like the proper compile environment on my Mac. Is the issue with the devpack tar extraction a problem in this regard? It appears that devpack materials are properly extracted to /usr/local... directories, but not to /Library/Frameworks/R.framework directories. It doesn't really matter because the devpack simply contains files that are otherwise shipped with R. I didn't get to see why it's not following the symlinks but if you install R form CRAN (or the nightly builds) you get those files anyway so you should be fine. BTW: in addition to the devpack there are many other libraries in http://r.research.att.com/libs/ which can be useful depending on the type of packages you're compiling from source. Thanks, Simon -Original Message- From: r-sig-mac-boun...@stat.math.ethz.ch [mailto:r-sig-mac- boun...@stat.math.ethz.ch] On Behalf Of Steven McKinney Sent: Monday, April 19, 2010 6:46 PM To: Simon Urbanek Cc: R-SIG-Mac@stat.math.ethz.ch Subject: Re: [R-SIG-Mac] Failed tar extract due to symlinks put in place by Rswitch Thanks for the information Simon. My apologies on the Rswitch misinformation. I nuked /Library/Frameworks/R.framework and reinstalled from http://r.research.att.com/ using the R-2.10-branch-leopard.pkg installer. The install yields the symlinks I saw previously (shown below). I still get the same error message on attempting to install the devpack. I'll try installing from CRAN as well. [momac13:/Library/Frameworks stevenmckinney] $ cd R.framework/ [momac13:/Library/Frameworks/R.framework stevenmckinney] $ ls -alF total 40 drwxrwxr-x@ 8 root admin 272 21 Oct 2008 ./ drwxrwxr-x@ 12 root admin 408 21 Oct 2008 ../ lrwxr-xr-x 1 root admin 24 19 Apr 18:33 Headers@ - Versions/Current/Headers lrwxr-xr-x 1 root admin 30 19 Apr 18:33 Libraries@ - Versions/Current/Resources/lib lrwxr-xr-x 1 root admin 31 19 Apr 18:33 PrivateHeaders@ - Versions/Current/PrivateHeaders lrwxr-xr-x 1 root admin 18 19 Apr 18:33 R@ - Versions/Current/R lrwxr-xr-x 1 root admin 26 21 Oct 2008 Resources@ - Versions/Current/Resources drwxrwxr-x 4 root admin 136 19 Apr 18:33 Versions/ [momac13:/Library/Frameworks/R.framework stevenmckinney] $ cd Versions/ [momac13:/Library/Frameworks/R.framework/Versions stevenmckinney] $ ls -alF total 8 drwxrwxr-x 4 root admin 136 19 Apr 18:33 ./ drwxrwxr-x@ 8 root admin 272 21 Oct 2008 ../ drwxrwxr-x 6 root admin 204 19 Apr 18:33 2.10/ lrwxr-xr-x 1 root admin4 19 Apr 18:33 Current@ - 2.10 [momac13:/Library/Frameworks/R.framework/Versions stevenmckinney] $ Steve McKinney From: Simon Urbanek [simon.urba...@r-project.org] Sent: April 19, 2010 6:26 PM To: Steven McKinney Cc: R-SIG-Mac@stat.math.ethz.ch Subject: Re: [R-SIG-Mac] Failed tar extract due to symlinks put in place by Rswitch On Apr 19, 2010, at 8:58 PM, Steven McKinney wrote: Hi all, I am attempting to install macosx tools to a new Mac Pro. When I attempt to install the devpack sudo tar fvxz /Users/stevenmckinney/Software/R/R-2.10.1/devpack4- darwin8-bin4.tar.gz -C / the tar extract fails due to symlink issues, related to symlinks set up by Rswitch. Rswitch does not setup any such symlinks. However, if you used Rswitch to switch to a broken version of R that would do the job. Has anyone else encountered this issue, and know of a fix? It seems as if you don't have a valid R installation -- please make sure you install R before unpacking the dev pack. If in doubt nuke /Library/Frameworks/R.framework and re-install R from CRAN. Cheers, Simon This is the output from the tar extract command: [momac13:/ stevenmckinney] $ sudo tar fvxz /Users/stevenmckinney/Software/R/R-2.10.1/devpack4- darwin8-bin4.tar.gz -C / x usr/ x usr/local/ x usr/local/bin/ x usr/local/bin/fc-cache x usr/local/bin/fc-cat x usr/local/bin/fc-list . . . x usr/local/share/man/man5/png.5 x Library/ x Library/Frameworks/ x Library/Frameworks/R.framework/ x Library/Frameworks/R.framework/Resources/ x Library/Frameworks/R.framework/Resources/fontconfig/: Cannot extract through symlink Library/Frameworks/R.framework/Resources x Library/Frameworks/R.framework/Resources/fontconfig/cache/: Cannot extract through symlink Library/Frameworks/R.framework/Resources x Library/Frameworks/R.framework/Resources/fontconfig/fonts/: Cannot extract through symlink Library/Frameworks/R.framework/Resources x Library/Frameworks/R.framework/Resources/fontconfig/fonts/conf.avail/: Cannot extract through symlink Library/Frameworks/R.framework/Resources x Library/Frameworks/R.framework/Resources
Re: [R-SIG-Mac] getting history() to work
David, I think I can help you with that one -- I assume you did not hit Enter, Tab or any other key to commit the filename so it was never stored. When you're typing the file name it is not stored until you're finished with that field (i.e. when you close R before doing so it is taken as canceling the change). I agree that it can be a source of frustration - I'll see if we can change the behavior to auto-commit the change when the preference pane is closed (it's a little tricky because the pane is sort of independent of the window). Cheers, Simon On Apr 13, 2010, at 6:13 , David wrote: OK, I finally (think I) understand how the history mechanism interacts or fails to interact with R.app, as a result of Simon's postings--- clarity at last! R.app still seems to be behaving strangely on my system---for example, I was unable to implement Rob Goedman's suggestions. So I proceeded as follows. 1. Use shell command to delete my plist file in ~/Library/Preferences. 2. Look through ~/.Rprofile to make sure there is no interaction with history mechanism. 3. Delete all other files beginning with .R in my home directory. 4. Upload dmg with the latest version (2.10.1) of R.app that works on Tiger. (Note to myself: must upgrade to Leopard.). Install 2.10.1. 5. If I now open R.app and then do RPreferencesStartUpchange name of history file to .Rapphistory then close R.app using any of the R.app methods (NOT q()), then open R.app again, I find the SAME default entry for my history file, namely .Rhistory. I haven't tried direct editing of the plist file while R is closed. Further information: While closing R.app, I kept on looking at the plist contents. Following on 1. above, the plist file did not exist. The preferences menu still showed my new name, namely .Rapphistory. I closed the preferences window, opened it again: still .Rapphistory. I pressed the quit light switch on the GUI. The plist file appeared for the first time in ~/Library/Preferences, with keyHistory file path used for R type history files/key string.Rhistory/string I still had not finally quit from R.app. When asked whether I wanted to save or cancel or not save, I clicked on cancel. Then I went again to RPreferencesStartUp and the name of the history file in the Preferences menu had reverted to .Rhistory. Can anyone think of a reason why R.app is insisting on using the default .Rhistory, and does not accept my attempts to change it? Are there any more diagnostic features I can try? Does anyone else, working under Tiger, find the same behaviour with 2.10.1? Thanks for any help David R 2.10.1 GUI 1.31-np Tiger build 32-bit (5538) MacOsX 10.4.11 running on PowerPC G4 ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] getting history() to work
On Apr 12, 2010, at 4:36 , David Winsemius wrote: On Apr 8, 2010, at 11:45 AM, David wrote: On 8 Apr, 13:32, David Winsemius dwinsem...@comcast.net wrote: On Apr 8, 2010, at 4:56 AM, David wrote: When I type history() to the R console, I get a new window that is always blank. How can I get history() working? ...[snip]... It's been a whiles since I used R 2.8 but perhaps the current behavior is similar. What happens when you: A) Open the Preferences dialog in the RGUI and look at your history settings (which in the current GUI are in the Startup panel.) Looks normal to me. Setting relating to history seem OK. Should I send you personally a screen shot? I don't think I can attach an image for the whole forum. In Preferences, the history file was listed as .Rhistory. I tried to change this to ~/.Rhistory, but when I closed R and reopened it, it reverted to .Rhistory. (I use the GUI, so this may or may not parallel your experience.) When I execute history() from the GUI console, a file opens up with about 20 commands that I have not used recently. When I choose Save as it offers the name hist496ef7b9 and the location is a temp directory fairly deep in the /private/var/... directories. It looks like I was wrong about thinking that such files would always be given an .Rhistory name. I get the recent historical entries in the GUI by clicking the Show/Hide History icon. I suspect that the history() function is more useful in the command line initiated sessions of R but not normally used in the GUI sessions. In the GUI the current history is accessed on the console (arrow keys) or via the history panel (Show/Hide History in the toolbar). That is the only supported way to interact with the current history. The history() command only shows the last saved history as a file - i.e. essentially the history file in the preferences. The history is not saved until you close the console window or use the R - Quit menu item. ( A side note: R.app does NOT support the q() or quit() functions since they save neither history nor open files). Cheers, Simon B) Open a Terminal.app window and type in: locate .Rhistory I got a large number of hits. I recognized all the directories as directories which had been, at one time or another, possibly with a different version of R, the working directory for some R program. I deleted all these hits as confusing the issue. I found one .Rhistory in the working directory, containing a single command that I almost certainly gave some time today. At some point today I deleted this file and it has been re-created with this single command in it. Nevertheless, history() continues to give me a blank screen. If things were operating as I wish, there would have been many commands in .Rhistory, since I have typed many commands to the R console today. ...[snip]... David ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] getting history() to work
On Apr 12, 2010, at 11:15 , Ben Madin wrote: Simon et al, On 12/04/2010, at 22:41 , Simon Urbanek wrote: A side note: R.app does NOT support the q() or quit() functions since they save neither history nor open files I was totally unaware of this being the case (as one still gets the Save workspace image? [y/n/c]: message), and as this would probably have saved me lots of grief in the past - I gave up using the history and work from scripts always - maybe it could be a little more clearly noted somewhere else. My request / suggestion would be a warning every time the GUI opens that this is the case until the user checks the box that says OK, I'll remember that for the future I have added a warning if you use q/quit in the GUI - that should be more clear. Thanks, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Nightly build gui framework mismatch
On Mar 31, 2010, at 3:07 , Prof Brian Ripley wrote: Yes, there is currently no binary of 2.11.x on Simon's site. But there are (it claims) binaries of R.app for 2.12.x, as well as 2.11.x and 2.10.x. The binary was built (hence the GUI had it) but it didn't make it to the web server. Thanks, Simon Given that we would like people to test 2.11.0 alpha this is unfortunate (but then the alpha snapshots have been broken several times over the past week, but those for the last couple of days do work). You can always build from the sources. On Tue, 30 Mar 2010, Peter Cowan wrote: Hi all, I checked the archives and didn't see this come up, but I'm not subscribed to the list so I apologize if this has been discussed. I'm using OS X 10.6.3 on 64bit Intel. I tried to download the nightly tarball and GUI and got an error message saying R cannot be opened because of a problem, the bug report output is appended below. It appears to be a mismatch where the GUI is looking for R 2.11.0 (what I was hoping to install) yet the latest tarball seems to install framework version 2.12. I did not see a 2.11 tarball for leopard available. I also noticed that the most recent nightly is from March 26. Lastly, I'm trying to update to confirm that the behavior of bug.report() in R.app (the gui). This new function tries to open an editor to fill out a bug report. In the terminal this is vim, and when I last tried it in R.app, it also tried to open vim which didn't quite work. It would be ideal if it would open the editor I set as the default in R.app, but I understand this may require additional complexity in the R function. Cheers Peter Process: R [371] Path:/Applications/R.app/Contents/MacOS/R Identifier: org.R-project.R Version: ??? (???) Code Type: X86-64 (Native) Parent Process: launchd [167] Date/Time: 2010-03-30 17:44:33.740 -0700 OS Version: Mac OS X 10.6.3 (10D573) Report Version: 6 Interval Since Last Report: 965 sec Crashes Since Last Report: 8 Per-App Crashes Since Last Report: 8 Anonymous UUID: 0030AE26-A54B-4C12-BE92- F23AA5E8427A Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0002, 0x Crashed Thread: 0 Dyld Error Message: Library not loaded: /Library/Frameworks/R.framework/Versions/2.11/Resources/lib/ libR.dylib Referenced from: /Applications/R.app/Contents/MacOS/R Reason: image not found ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- 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-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] package with fortran failing to install
On Mar 29, 2010, at 18:08 , Devin Johnson wrote: After installing Xcode again (3.2.1) I get the new error when building from the source posted on CRAN $ R CMD INSTALL crawl_1.1-0.tar.gz * installing to library ‘/Users/johnsond/Library/R/’ * installing *source* package ‘crawl’ ... ** libs ** arch - i386 gfortran-4.2 -arch i386 -fno-common -mtune=core2 -g -O2 -c crwDriftN2ll.f90 -o crwDriftN2ll.o crwDriftN2ll.f90:0: error: bad value (core2) for -mtune= switch make: *** [crwDriftN2ll.o] Error 1 ERROR: compilation failed for package ‘crawl’ * removing ‘/Users/johnsond/Library/R//crawl’ * restoring previous ‘/Users/johnsond/Library/R//crawl’ Is there something else that disappeared with my upgrade to SL? Or is this now a gfortran problem? The problem is still the same - you failing to read the docs! If you bothered to read the e-mails you'd know that you have to install Xcode 3.2 (or 3.2.1) and the corresponding Fortran from http://r.research.att.com/tools/ Cheers, Simon On Mar 29, 2010, at 2:18 PM, Simon Urbanek wrote: On Mar 29, 2010, at 16:45 , Devin Johnson wrote: Hi, I have a problem compiling/installing a package that has fortran source code in it. I've compiled earlier versions of this package many times in the past as I've worked on it, but, now it's failing to install. I've recently go through an upgrade to snow leopard and installation/migration of my home directory for networking purposes at work (use AdmitMac with a domain account). I'm not sure which one of these might be causing the issue. Everything was fine before this. Here's the error: $ R CMD INSTALL crawl * installing to library ‘/Users/johnsond/Library/R/’ * installing *source* package ‘crawl’ ... ** libs ** arch - i386 sh: make: command not found Please see the FAQ - you don't even have Xcode installed. Cheers, Simon ERROR: compilation failed for package ‘crawl’ * removing ‘/Users/johnsond/Library/R//crawl’ * restoring previous ‘/Users/johnsond/Library/R//crawl’ Here's the gfortran version: $ gfortran --version GNU Fortran (GCC) 4.2.3 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 $ which gfortran /usr/local/bin/gfortran The package (crawl) is currently on CRAN and when I download the source, I get the same message. I've tried reinstalling R 2.10.1, gfortran 2.4.3, and poking around where I could, but I'm at a loss for what to check next. Any help would be greatly appreciated. -- Devin S. Johnson, Ph.D. Statistician NOAA National Marine Mammal Laboratory 7600 Sand Point Way NE Seattle, WA 98115 Phone: (206) 526-6867 Fax: (206) 526-6115 Email: devin.john...@noaa.gov -- [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac -- Devin S. Johnson, Ph.D. Statistician NOAA National Marine Mammal Laboratory 7600 Sand Point Way NE Seattle, WA 98115 Phone: (206) 526-6867 Fax: (206) 526-6115 Email: devin.john...@noaa.gov -- ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] embed r in cpp with xcode
FWIW a good starting point is the stand-alone REngine https://svn.r-project.org/R-packages/branches/stand-alone-REngine I have added an Xcode project so it should be easy to get going. However, the main language in Mac OS X is Obj-C so it is left to the user to decide how to go forward - either use the REngine Obj-C API or call R directly from C/C++ after it has been initialized. It is also trivial to switch the test code to Obj-C++ if desired. Cheers, Simon On Mar 22, 2010, at 4:00 PM, Mansour CHOUAHA wrote: Hi, Can anyone tell me how to embed R code in a C++ file. I am actually using a mac running on the OSX 10.6.2 and the IDE Xcode Version 3.2 and I would like to embed the basic function like geometric, binomial, normal and hyper geometric distributions in a sample cpp file. I heard about the library RInside and i have downloaded the source code for mac but i do not know how to build it in order to use it with my IDE XCode. Could anyone help me step by step because I am new in programming to show me how to get this done? Thanks for your help. Mans. _ Hotmail: Free, trusted and rich email service. [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] brief RMySQL walkthrough
Kyle, is there a particular reason why to not use a much simpler install.packages(RMySQL) You don't need any of the stuff below to use it ... Cheers, Simon On Mar 25, 2010, at 14:18 , Kyle Matoba wrote: All, Here are the steps I went through to install RMySQL on Snow Leopard this morning ( March 25, 2010 ): Download and install mySQL: http://dev.mysql.com/downloads/mysql/ (MySQL Community Server 5.1.45) Download the client libraries: http://dev.mysql.com/downloads/connector/c/ (Connector/C 6.0.2) Obtain the source: http://cran.r-project.org/src/contrib/RMySQL_0.7-4.tar.gz Unpack the source (in finder, e.g.) Unpack the client libraries, copy the /include and /lib directories into the corresponding in /usr/local/mysql/ or wherever you installed mySQL. Compile the source: R CMD INSTALL --configure-args='--with-mysql-dir=/usr/local/mysql --with-mysql-inc=/usr/local/mysql/include --with-mysql-lib=/usr/local/mysql/lib' ~/Downloads/RMySQL_0.7-4.tar Do not know if this is the most concise way of going about it, but it worked for me. For further reading I recommend Jeff's exchange of April 30, 2009. Regards, Kyle ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] brief RMySQL walkthrough
On Mar 25, 2010, at 14:25 , Simon Urbanek wrote: Kyle, is there a particular reason why to not use a much simpler install.packages(RMySQL) I think I can now answer that question -- the CRAN machine did not have 64-bit Intel binaries of MySQL, so the x86_64 architecture of the CRAN binary did not work (i386 and ppc did work). It is fixed now. (Lesson: please report such issues instead of hacking around them!) Thanks, Simon You don't need any of the stuff below to use it ... Cheers, Simon On Mar 25, 2010, at 14:18 , Kyle Matoba wrote: All, Here are the steps I went through to install RMySQL on Snow Leopard this morning ( March 25, 2010 ): Download and install mySQL: http://dev.mysql.com/downloads/mysql/ (MySQL Community Server 5.1.45) Download the client libraries: http://dev.mysql.com/downloads/connector/c/ (Connector/C 6.0.2) Obtain the source: http://cran.r-project.org/src/contrib/RMySQL_0.7-4.tar.gz Unpack the source (in finder, e.g.) Unpack the client libraries, copy the /include and /lib directories into the corresponding in /usr/local/mysql/ or wherever you installed mySQL. Compile the source: R CMD INSTALL --configure-args='--with-mysql-dir=/usr/local/mysql --with-mysql-inc=/usr/local/mysql/include --with-mysql-lib=/usr/local/mysql/lib' ~/Downloads/RMySQL_0.7-4.tar Do not know if this is the most concise way of going about it, but it worked for me. For further reading I recommend Jeff's exchange of April 30, 2009. Regards, Kyle ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] build of package xlsx fails on Mac
Adrian, I think I have a déjà vu: http://www.mail-archive.com/r-sig-mac@stat.math.ethz.ch/msg04964.html Cheers, Simon On Mar 9, 2010, at 11:54 , Adrian Dragulescu wrote: Hello, One user pointed to me that the build of package xlsx fails on Mac. I did not change anything on CRAN since I've uploaded the package. I believe it used to work fine. The issue is Java specific as my package uses rJava. When running the examples, one gets: checking Rd contents ... OK checking examples ... ERROR Running examples in 'xlsx-Ex.R' failed. The error most likely occurred in: ### * CellStyle flush(stderr()); flush(stdout()) ### Name: CellStyle ### Title: Functions to manipulate cells. ### Aliases: CellStyle createCellStyle setCellStyle getCellStyle ### ** Examples wb - createWorkbook() sheet - createSheet(wb, Sheet1) rows - createRow(sheet, rowIndex=1) cell.1 - createCell(rows, colIndex=1)[[1,1]] setCellValue(cell.1, Hello R!) cellStyle1 - createCellStyle(wb, borderPosition=RIGHT, + borderPen=BORDER_DASHED, fillBackgroundColor=yellow, + fillForegroundColor=tomato, fillPattern=BIG_SPOTS) 2010-02-15 12:47:54.174 R[33120:613] Apple AWT Java VM was loaded on first thread -- can't start AWT. Error in .jnew(java.awt.Color, rgb[1], rgb[2], rgb[3]) : java.lang.NoClassDefFoundError Calls: createCellStyle - .jcall - .xssfcolor - .jnew - .External Execution halted Let me know if there is something on my side that I need to do. Of course, I can \dontrun the example. Thank you, Adrian -- Forwarded message -- Date: Mon, 8 Mar 2010 14:41:40 -0800 From: Ralf Tautenhahn rtaut...@scripps.edu To: Adrian Dragulescu adria...@eskimo.com Subject: RE: xlsx and binary data Hi Adrian, I see that the xlsx build fails on Mac: http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/xlsx-00check.html I hope this is only a temporary problem ? Regards, Ralf. ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Wrong locale when using R from shell
On Mar 22, 2010, at 6:06 PM, Erich Studerus wrote: I typed export into the mac terminal to see the setup of my system variables. Under language I get LANG=de_CH.UTF-8. So it seems my system variable for language is set up correctly. Nope ;). I assume you're looking in Terminal which sets the LANG variable according to its preferences - it is NOT set by the shell. It doesn't make sense that Lyx would force C locale, although I don't know where I can check this. I'm using the regular Lyx/Sweave setup described here: http://wiki.lyx.org/LyX/LyxWithRThroughSweave I dont have this locale problem on my Windows 7 computer. I don't understand, why R can dectect the correct locale when started from the terminal or as R.app but not from the shell. How do these running modes differently look up environmental variables? Both of them set LANG explicitly - it's that easy. Apparently LyX doesn't. Again, you're barking up the wrong tree - it's not R's fault since R gives you what you ask for - namely the C locale. If LyX uses a shell to run R, it should be as easy as replacing R with LANG=en_US.UTF-8 R or whichever you prefer. I don't use LyX so I don't know what where exactly you have to change it. Note that the locale is NOT changed in the system-wide startup scripts (by default). Cheers, Simon Regards, Erich On Mon, 22 Mar 2010 17:09:21 -0400 Simon Urbanek simon.urba...@r-project.org wrote: On Mar 22, 2010, at 16:32 , Erich Studerus wrote: Hello I'm using Lyx with Sweave on Mac OS X 10.5.8 with R version 2.10.1. When I compile Lyx documents, R is called from shell to process R code chunks contained in the Lyx document. Unfortunately, R does not automatically detect the correct locale when called from shell. I figured out that R uses the C locale in shell mode by embedding the following code in Lyx echo=F= sys.getlocale() @ When I start R from the terminal and also in the R.app I get the correct locale: de_CH.UTF-8/de_CH.UTF-8/C/C/de_CH.UTF-8/de_UTF-8 How I can I get the correct locale when calling R from shell? Setup your environment accordingly? This has nothing to do with R but your environment (LANG, LANGUAGE, LC_xxx) - which is what determines the locale. The default locale settings are system-dependent, so either your system default locale is C or Lyx forces C locale for the shell it starts. For details on locale specifications see, e.g.: http://www.gnu.org/software/hello/manual/gettext/Locale-Environment-Variables.html#Locale-Environment-Variables http://opengroup.org/onlinepubs/007908799/xbd/envvar.html Cheers, Simon ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] rattle doesnt rattle (David Winsemius)
On Mar 20, 2010, at 7:44 AM, Luca Scrucca wrote: Dear Simon, I also have problem with rattle. On a MBP running OSX 10.5.8, with R 2.10.1, and the latest rattle package installed after installing GTK+ 2.18.5 framework (the one available on the link you kindly provided), I obtained the following: Make sure you have X11 installed and running. However, probably the right place to report this is rattle authors/mailing list since it may also be an issue with insufficient error checking ... Cheers, Simon library(rattle) Loading required package: pmml Loading required package: XML Rattle: Graphical interface for data mining using R. Version 2.5.24 Copyright (c) 2006-2010 Togaware Pty Ltd. Type 'rattle()' to shake, rattle, and roll your data. rattle() Error in theWidget(rattle_window) : attempt to apply non-function Rattle timestamp (for the error above): 2010-03-20 12:27:42 (process:6306): GLib-GObject-CRITICAL **: ../../glib-2.23.0/gobject/gtype.c:2458: initialization assertion failed, use g_type_init() prior to this function (process:6306): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (process:6306): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed (process:6306): libglade-CRITICAL **: glade_xml_construct: assertion `self != NULL' failed (process:6306): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed sessionInfo() R version 2.10.1 (2009-12-14) i386-apple-darwin9.8.0 locale: [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 attached base packages: [1] graphics utils datasets grDevices stats methods base other attached packages: [1] RGtk2_2.12.18 colorspace_1.0-1 rattle_2.5.24 pmml_1.2.21 [5] XML_2.6-0 RColorBrewer_1.0-2 rgl_0.89 loaded via a namespace (and not attached): [1] tools_2.10.1 Luca -- Luca Scrucca Dipartimento di Economia, Finanza e Statistica Sezione di Statistica Università degli Studi di Perugia Via A. Pascoli, 20 06123 PERUGIA (ITALY) Tel. +39-075-5855233 Fax. +39-075-5855950 E-mail: l...@stat.unipg.it Web page: http://www.stat.unipg.it/luca ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Makeconf and GCC version: Leopard vs Snow Leopard
On Mar 17, 2010, at 9:38 AM, Simon Anders wrote: Hi Simon etc. We've recently got a number of question from users of our packages, who, for certain reasons, wanted to compile them from source on a Mac, and ran into problems, namely the error message that 'gcc-4.2' was not found. I don't know if the issue has already been discussed but as I've just investigated it, It is worth checking the archives - it would give you the correct answer. It is simply about outdated Xcode. We require Xcode 3.1 or higher for Leopard builds -- see http://r.research.att.com/tools/ mainly because of issues in older Xcodes. The latest Xcode for 10.5 is Xcode 3.1.4 and is at the top of the Xcode download list in ADC (=easy to find). Admittedly, the Tiger build requirement (Xcode 2.4.0+)is in the FAQ, Leopard (Xcode 3.1+) is not -- I'll fix that. Thanks, Simon I would like to share my findings. (Note that I'm not a Mac user myself, so I am not too experienced with this.) It seems that the current version of Xcode (3.2.1) has the GNU Compiler Collection (GCC) in the version 4.2. Most users of Leopard have, however, the old Xcode 3.0 installed, which ships with GCC 4.0. (The Xcode 3.2.1 package presented on the Apple web site only works for Snow Leopard. There is an XCode 3.2.x for Leopard as well somewhere on the web site, but it is quite difficult to find.) I've just looked over the shoulder of a Mac user who had installed the pre-compiled binary from CRAN for R-2.11.0 (devel) on his Leopard machine with Xcode 3.0 installed. When he tried to run 'R CMD INSTALL' on a source package, he got the aformentioned error that 'gcc-4.2' was missing. The reason that R was explicitly looking for 'gcc-4.2' was that this is what the 'CC' variable was se to in Makeconf (to be precise: in /Library/Framework/R.framework/Resources/i386/Makeconf ) We changed, in the Makeconf file, 'gcc-4.2' to 'gcc' in the definition of 'CC', and likewise for 'g++-4.2' and 'gfortran-4.2' in the respective lines. (Note that all Xcode versions seem to install a symlink from the installed binary 'gcc-4.x' to 'gcc' and likewise for g++ and gfortran.) Furthermore, it was necessary to remove the compiler flag '-mtune=core2' from CC_FLAGS, CXX_FLAGS and FC_FLAGS, as this tuning target was not yet available in GCC 4.0. With this, building source packages worked fine. Conclusion: The precompiled R binary for Mac would be more compatible, namely working with the typical configuration of both Leopard and Snow Leopard if the Makeconf did not specify the exact GCC version and did not use the 'core2' tuning flag. Could we change this, please? Cheers Simon +--- | Dr. Simon Anders, Dipl.-Phys. | European Molecular Biology Laboratory (EMBL), Heidelberg | office phone +49-6221-387-8632 | preferred (permanent) e-mail: sand...@fs.tum.de ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How to interrupt an R process that hangs
On Mar 15, 2010, at 14:42 , Adam D. I. Kramer wrote: +1--this is the single most-annoying issue with R that I know of. My usual solution, after accomplishing nothing as R spins idly for a couple hours, is to kill the process and lose any un-saved work. save.history() is my friend, but is a big delay when you work with big data sets as I do, so I don't run it after every command. I have cc'd r-help here, however, because I experience this problem with non-OSX R as well...when I run it in Linux or from the OSX command- line (I compile R for Darwin without aqua/R-framework), the same thing happens. Is there some way around this? Is this a known problem? Hanging for a long period of time is usually caused by poorly written C/Fortran code. You can always interrupt R as long as it is in the R code. Once you load a package that uses native code (C/ Fortran/..) you have to rely on the sanity of the developer to call R_CheckUserInterrupt() or rchkusr() often enough (see 6.12 in R-ext). If you have some particular package that does not do that, I would suggest alerting the author. By definition this requires cooperation from authors, because interrupting random code forcefully (as it was possible many years ago) creates leaks and unstable states. Cheers, Simon Google searching suggests no solution, timeline, or anything, but the problem has been annoying users for at least twelve years: http://tolstoy.newcastle.edu.au/R/help/9704/0151.html Cordially, Adam On Mon, 15 Mar 2010, Matthew Keller wrote: HI all, Apologies for this question. I'm sure it's been asked many times, but despite 20 minutes of looking, I can't find the answer. I never use the GUI, I use emacs, but my postdoc does, so I don't know what to tell her about the following: Occasionally she'll mess up in her code and cause R to hang indefinitely (e.g., R is trying to do something that will take days). In these situations, is there an option other than killing R (and the work you've done on your script to that point)? Thank you, Matthew Keller -- Matthew C Keller Asst. Professor of Psychology University of Colorado at Boulder www.matthewckeller.com ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] How to interrupt an R process that hangs
On Mar 15, 2010, at 16:20 , Matthew Keller wrote:
Hi all,
Thanks Simon and Duncan for the help. Sorry to be dense, but I'm still
unsure how to interrupt such processes. Here's an example:
for (i in 1:10){
a - matrix(rnorm(10*10),ncol=10)
b - svd(a) }
If you run this,
How could I?
for (i in 1:10){
+ a - matrix(rnorm(10*10),ncol=10)
+ b - svd(a)}
Error in rnorm(1e+05 * 1e+05) : invalid arguments
In addition: Warning message:
In rnorm(1e+05 * 1e+05) : NAs introduced by coercion
The only way to run that code at all is to scale it down, e.g.
for (i in 1:10){
+ a - matrix(rnorm(1000*1000),ncol=1000)
+ b - svd(a)
+ }
and when interrupted it comes back within 5s on my Mac ...
I get your general point, but the fact remains that you cannot
interrupt native code unless it has provisions to do so. The reason is
that it is impossible to cleanup native code properly (i.e if the
author did not think of it) so R allows interruption only if the code
tells R that it is safe to do so.
R will hang (i.e., it's a legitimate execution, it
will just take a really long time to execute). The most obvious
solution is to write code that doesn't do unintended things, but
that's not always possible. Is there a way to interrupt it? I tried:
kill -s INT PID
and at least on Mac it had no effect.
.. if you are in C code, see above. Otherwise it interrupts the R code
(and so doe ^C or pushing the Stop button etc).
Cheers,
Simon
On Mon, Mar 15, 2010 at 1:19 PM, Simon Urbanek
simon.urba...@r-project.org wrote:
On Mar 15, 2010, at 14:42 , Adam D. I. Kramer wrote:
+1--this is the single most-annoying issue with R that I know of.
My usual solution, after accomplishing nothing as R spins idly for a
couple
hours, is to kill the process and lose any un-saved work.
save.history()
is
my friend, but is a big delay when you work with big data sets as
I do, so
I
don't run it after every command.
I have cc'd r-help here, however, because I experience this
problem with
non-OSX R as well...when I run it in Linux or from the OSX command-
line (I
compile R for Darwin without aqua/R-framework), the same thing
happens.
Is there some way around this? Is this a known problem?
Hanging for a long period of time is usually caused by poorly
written
C/Fortran code. You can always interrupt R as long as it is in the
R code.
Once you load a package that uses native code (C/Fortran/..) you
have to
rely on the sanity of the developer to call R_CheckUserInterrupt() or
rchkusr() often enough (see 6.12 in R-ext). If you have some
particular
package that does not do that, I would suggest alerting the author.
By
definition this requires cooperation from authors, because
interrupting
random code forcefully (as it was possible many years ago) creates
leaks and
unstable states.
Cheers,
Simon
Google searching suggests no solution, timeline, or anything, but
the
problem has been annoying users for at least twelve years:
http://tolstoy.newcastle.edu.au/R/help/9704/0151.html
Cordially,
Adam
On Mon, 15 Mar 2010, Matthew Keller wrote:
HI all,
Apologies for this question. I'm sure it's been asked many times,
but
despite 20 minutes of looking, I can't find the answer. I never use
the GUI, I use emacs, but my postdoc does, so I don't know what to
tell her about the following:
Occasionally she'll mess up in her code and cause R to hang
indefinitely (e.g., R is trying to do something that will take
days).
In these situations, is there an option other than killing R (and
the
work you've done on your script to that point)?
Thank you,
Matthew Keller
--
Matthew C Keller
Asst. Professor of Psychology
University of Colorado at Boulder
www.matthewckeller.com
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Matthew C Keller
Asst. Professor of Psychology
University of Colorado at Boulder
www.matthewckeller.com
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] build of package xlsx fails on Mac (fwd)
Adrian,
On Mar 9, 2010, at 13:50 , Adrian Dragulescu wrote:
Simon,
I got bounced as a non-member. Maybe you are in the best position
to have an opinion on this.
Yes, since OS X 10.5 Apple dropped support for AWT on the main thread,
so essentially you cannot use any graphics classes in R on OS X 10.5
since R is single-threaded. They work in JGR, though.
This is a bit problematic for tests and I don't have a good solution.
I have a hack that you're welcome to use -- when checking packages on
OS X 10.5 we set NOAWT=1 so you could make your graphics tests
conditional on
if (!nzchar(Sys.getenv(NOAWT))) {
## AWT/Swing tests here
}
It's not pretty but that's all I can offer at the moment .. Ideally
Apple would fix that issue but ...
Cheers,
Simon
(CCing to R-SIG-Mac as that seems to have been intended)
-- Forwarded message --
Date: Tue, 9 Mar 2010 08:54:35 -0800 (PST)
From: Adrian Dragulescu adria...@eskimo.com
To: r-sig-mac@stat.math.ethz.ch
Subject: build of package xlsx fails on Mac
Hello,
One user pointed to me that the build of package xlsx fails on Mac.
I did not change anything on CRAN since I've uploaded the package.
I believe it used to work fine.
The issue is Java specific as my package uses rJava. When running
the examples, one gets:
checking Rd contents ... OK
checking examples ... ERROR
Running examples in 'xlsx-Ex.R' failed.
The error most likely occurred in:
### * CellStyle
flush(stderr()); flush(stdout())
### Name: CellStyle
### Title: Functions to manipulate cells.
### Aliases: CellStyle createCellStyle setCellStyle getCellStyle
### ** Examples
wb - createWorkbook()
sheet - createSheet(wb, Sheet1)
rows - createRow(sheet, rowIndex=1)
cell.1 - createCell(rows, colIndex=1)[[1,1]]
setCellValue(cell.1, Hello R!)
cellStyle1 - createCellStyle(wb, borderPosition=RIGHT,
+ borderPen=BORDER_DASHED, fillBackgroundColor=yellow,
+ fillForegroundColor=tomato, fillPattern=BIG_SPOTS)
2010-02-15 12:47:54.174 R[33120:613] Apple AWT Java VM was loaded on
first thread -- can't start AWT.
Error in .jnew(java.awt.Color, rgb[1], rgb[2], rgb[3]) :
java.lang.NoClassDefFoundError
Calls: createCellStyle - .jcall - .xssfcolor - .jnew - .External
Execution halted
Let me know if there is something on my side that I need to do. Of
course, I can \dontrun the example.
Thank you,
Adrian
-- Forwarded message --
Date: Mon, 8 Mar 2010 14:41:40 -0800
From: Ralf Tautenhahn rtaut...@scripps.edu
To: Adrian Dragulescu adria...@eskimo.com
Subject: RE: xlsx and binary data
Hi Adrian,
I see that the xlsx build fails on Mac:
http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/xlsx-00check.html
I hope this is only a temporary problem ?
Regards,
Ralf.
___
R-SIG-Mac mailing list
R-SIG-Mac@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] RODBC
On Mar 6, 2010, at 12:17 PM, Ivan Calandra wrote: Dear Mac users, Up to now, I've run R on Windows and I have some problems using my scripts on Mac OS X 10.6, R.app GUI 1.31 (5537 Leopard build 64-bit). Here is the code I use to export a data.frame to an *.xls file: xlsFile - odbcConnectExcel(test.xls, readOnly=F) sqlSave(xlsFile, test, tablename=test, rownames=F, addPK=T, append=F) odbcCloseAll() However, the function odbcConnectExcel() doesn't work on Mac. Have you installed the necessary ODBC drivers and registered them? Cheers, Simon Could you help me transposing this code? I don't think some sample data would be necessary, but let me know if you would like to. Thanks in advance Regards, Ivan -- Ivan CALANDRA PhD Student University of Hamburg Biozentrum Grindel und Zoologisches Museum Abt. Säugetiere Martin-Luther-King-Platz 3 D-20146 Hamburg, GERMANY +49(0)40 42838 6231 ivan.calan...@uni-hamburg.de ** http://www.for771.uni-bonn.de http://webapp5.rrz.uni-hamburg.de/mammals/eng/mitarbeiter.php [[alternative HTML version deleted]] ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] Building binaries of OpenMx [Was: libgfortran misplaced in Mac OS X R install]
/ libRblas.dylib (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libRlapack.dylib (compatibility version 2.10.0, current version 2.10.1) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libR.dylib (compatibility version 2.10.0, current version 2.10.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ CoreFoundation (compatibility version 150.0.0, current version 476.19.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib (compatibility version 1.0.0, current version 242.0.0) If you are dealing with only one R version, you can change the ID of your Fortran library instead of touching the package files: install_name_tool -id \ /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libgfortran.2.dylib /usr/local/lib/libgfortran.2.0.0.dylib Note, however, that this will lead to (possibly silent) errors if you forget to change it when switching to another R version, so I prefer to fix the package instead. Cheers, Simon The beta test users install the package using the following script: http://openmx.psyc.virginia.edu/getOpenMx.R . On Wed, Mar 3, 2010 at 9:48 AM, Tim Brick tbr...@virginia.edu wrote: From: Simon Urbanek simon.urba...@r-project.org Date: March 3, 2010 8:32:52 AM MST To: tbr...@virginia.edu Cc: r-de...@stat.math.ethz.ch, r-b...@r-project.org Subject: Re: [Rd] libgfortran misplaced in Mac OS X R install (PR#14226) This is not an R bug so please don't abuse R-bugs. It is likely a bug in the way OpenMx binaries are distributed by someone (you didn't even say where you got them from) - OpenMx is not even on CRAN so take that to whoever gave you the binaries. On CRAN we use the correct paths. Cheers, Simon On Mar 2, 2010, at 11:45 , tbr...@virginia.edu wrote: Full_Name: Timothy Brick Version: 2.10 OS: Mac OS X (seen on both 10.6 and 10.5) Submission from: (NULL) (63.255.24.5) When using install.packages in R on Mac OS X, packages that require gfortran throws an error (Example below from installation of OpenMx package): Loading required package: OpenMx Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/Library/Frameworks/R.framework/Resources/library/OpenMx/libs/ i386/OpenMx.so': dlopen(/Library/Frameworks/R.framework/Resources/library/OpenMx/ libs/i386/OpenMx.so, 6): Library not loaded: /usr/local/lib/libgfortran.2.dylib Referenced from: /Library/Frameworks/R.framework/Resources/ library/OpenMx/libs/i386/OpenMx.so Reason: image not found libgfortran.2.dylib does exist, but in /Library/Frameworks/R.framework/Versions/2.10/Resouces/lib/ libgfortran.2.dylib (or /2.9/, depending on version installed). A workaround at present involves creating a symbolic link from the above file to /usr/local/lib/libgfortran.2.dylib, however this requires sudo access and is confusing for novice users. There is more discussion of this bug as it relates to OpenMx at: http://openmx.psyc.virginia.edu/thread/316 Posts on other forums indicate a similar issue with other packages including vegan and lme4: http://r-forge.r-project.org/forum/forum.php?thread_id=728forum_id=194 https://stat.ethz.ch/pipermail/r-sig-mac/2009-May/006210.html Those are very old posts and those were temporary issues in the CRAN build system that have been promptly resolved. __ r-de...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ r-de...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel ___ R-SIG-Mac mailing list R-SIG-Mac@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] distributable binary Mac packages [Was: libgfortran misplaced in Mac OS X R install]
On Mar 4, 2010, at 14:44 , Prof Brian Ripley wrote: Another possibility is to link statically to libgfortran. That has pros and cons, but for libgfortran not many cons apart from space for multiple copies in sundry packages (and is what is done on Windows, BTW). There are several ways to arrange that. As far as I recall I temporarily removed /usr/local/lib/libgfortran*.dylib: another way is to edit FLIBS in Makeconf (but then you do need to know which copies of that file you need to edit). The Xcode add-on compilers from R.research.att.com use static libgfortran by default, so if you didn't install any other Fortran, that will be the default. However, there are issues when linking multiple modules that also link libgfortran statically - dylibs are not allowed to contain multiple common symbols on OS X (with flat namespaces) which is the case if you get static libgfortran from two sources independently. The most prominent example is libRlapack linked into a package that also uses Fortran (that's why CRAN Rlapack does not use static libgfortran). There are ways around, but it all makes the already complex issue even more complex ;). As far as I know we don't document in the standard manuals how to build distributable binary Mac packages, and perhaps we should do so in due course (or at least point at where the information can be found). Yes, I agree. There are bits and pieces in the R for Mac FAQ, but it may be worth putting what I wrote below into the FAQ. Thanks, Simon On Thu, 4 Mar 2010, Simon Urbanek wrote: Hi Michael, On Mar 3, 2010, at 12:01 , Michael Spiegel wrote: I am the guy who compiles the OpenMx binaries. We would be delighted to place our package on CRAN, once the project is stable enough so that we are comfortable releasing it to the larger public. Let's try to track down where I made a mistake. Our Makevars.in file contains the line: PKG_LIBS=$(FLIBS) $(BLAS_LIBS) $(LAPACK_LIBS) In addition, on the build machine I noticed that a copy of libgfortran.2.dylib exists at /usr/local/lib. I believe the Xcode install placed a copy of it there. No, it is part of the GNU Fortran installation. Anything you compile with a Fortran requires that you have that Fortran installed at run time, because Fortran uses its own run-time libraries (if the Fortran you compiled with used dynamic libraries). This implies that if you distribute your package you have to tell users to install the same Fortran you used to compile it. However, unlike other unices Mac users don't necessarily have development tools installed, so on CRAN we make an effort to modify the binaries such that they work even without the tools they have been compiled with. There are several possible approaches, but since R itself already uses the same Fortran, we ship a copy of the Fortran libraries inside R and modify packages such that they use it instead of the one from dev tools (see below for details). To create the binary release, I run R CMD INSTALL --build. That is not sufficient to create a binary of your package, because it contains a configure script (this is unrelated to the above - see R-admin 2.6). What you want to use is something like this (assuming R 2.10.1 Leopard build and Fortran from CRAN): R --arch=i386 CMD INSTALL OpenMx_0.2.9-1147.tar.gz R --arch=x86_64 CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz R --arch=ppc CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz cd /Library/Frameworks/R.framework/Versions/2.10/Resources/library # fix the Fortran paths to point to R 2.10 instead for lib in `ls OpenMx/libs/*/*.so`; do install_name_tool -change /usr/local/lib/libgfortran.2.dylib \ /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libgfortran.2.dylib \ $lib done # change permissions for distribution sudo chown -Rh root:admin OpenMx sudo chmod -R g+w OpenMx # pack it up tar fvcz ~/OpenMx_0.2.9-1147.tgz OpenMx You can check that you have the correct paths using otool -L: ginaz:library$ otool -L OpenMx/libs/*/*.so OpenMx/libs/i386/OpenMx.so: OpenMx.so (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libgfortran.2.dylib (compatibility version 3.0.0, current version 3.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libRblas.dylib (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libRlapack.dylib (compatibility version 2.10.0, current version 2.10.1) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libR.dylib (compatibility version 2.10.0, current version 2.10.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ CoreFoundation (compatibility version 150.0.0, current version 476.19.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib
