Simon, First of all I really appreciate your responses and of course the work you've done. I may not completely agree with some design decisions, but anyway it is great to have such nice GUI for Mac version of R - IMHO the best GUI of all platforms.
> a) 3-way fat R.app (your proposal) vs 2-way fat R.app + 1-way R64.app (CRAN > release). > This is entirely a choice of convention and we have decided to separate > 32-bit binaries from the 64-bit binary for convenience of the user. As I said > there are several reason for this. Whether you like it or not is quite > irrelevant - it may not be what Safari does but then Safari is not a stat > computing language. Whether you use lipo to add the 64-bit binary to R.app or > not is purely cosmetic, it doesn't change the fundamental functionality > (except that with R.app+R64.app you can run them in parallel and start the > desired architecture more easily - and the user knows what he gets and > doesn't need to guess - less relevant for Safari, more so for R). You're looking on it from developer's perspective. But regular user that want to make few plots via R do not necessarily know what is 64-bit at all. That's why on Mac there's a convention to use FAT binaries and default to 64-bit unless you specify otherwise (like via Finder properties for an app) or there's no capable CPU. All this are for sake of consistency and single experience for all apps. This is what makes Mac/OSX different from Windows for example - conventions like similar UI for all apps, same keyboard shortcuts for same tasks, same places where every app places its configuration files. So IMHO every developer should ask himself when there comes an idea of making things "better" or "different" that break convention, whether it will really make things better or will lead to confusion. Just to be clear, I do agree with you in general, that R user should be able to choose between 32-bit and 64-bit version, but this can be done without breaking the OSX conventions, via Finder. Probably I shouldn't be so picky about Mac's R GUI because it is really great, but I just feel it isn't right when some apps behave "different", like placing files in folders I do not expect them to do, etc. etc. > b) multi-lib approach in R itself: (for packages, modules etc.). This is > deliberate and I was illustrating that it is very common even in OS X as you > can see in the gcc example. The main reason is portability because this way > the build system needs to be implemented only once for all platforms. This is > hidden from the user so you should not care. If you do, you may need to read > up on it. Sorry but I have to say that. You GCC example is just wrong. GCC is compiler and the folders you mention /usr/lib/gcc/*/4.2.1 are the program DATA not executable code, so these x86_64 folders inside have nothing to do to GCC program executable code itself (i.e. in ARM GCC toolchain these can refer to ARM architecture, while the compiler can run on Intel). GCC executable code as shown via `file /usr/bin/gcc` or `file /usr/lib/libgcc_s.1.dylib` is FAT binary, so Apple does not make any exception here. They do use FAT binaries everywhere. > c) decision to run 32-bit vs 64-bit binaries. This we leave entirely to the > user. You may not be familiar with the details (the link you quoted below is > quite irrelevant in the sense that the biggest waste of memory is not on the > stack - unless you use deep recursion), but each of the architectures has its > weaknesses and advantages. For low-memory machines it is often advisable to > use 32-bit binary as the benefits of the 64-bit instruction set are really > not that big (and the numerical stability is different, some would say > worse). 64-bit binary *always* uses more memory, by definition, that's not > even a question. The question is only how much more, and in some practical > settings it can be close to 100% more. But, again, we leave this to the user. I never said that 64-bit version use less memory. But saying that 64-bit version can have twice memory usage than 32-bit version is kind of over interpretation. For sure it will (nearly) double its executable size, and also stack memory, but heap (which occupies I believe ~95% memory space in most of uses) won't grow much unless you use memory structures that are made only from pointers. All other types do not change their size in 64-bit, doubles, ints remain same size, at least for AMD64 (not talking here about Sparc or PPC64 :>) As for memory please also not that 32-bit app 4GB addressing limit is in fact much less, rather close to ~1-1.5GB, because of two factors: VM address space fragmentation, address space range for kernel. > d) "How to make Mac 64-bit version feature complete?" Well, the CRAN 64-bit > version of R *is* feature complete so the question goes off an invalid > assumption. Later you mentioned rgl, but that is not part of R. Yes I did false assumption that there's something wrong with 64-bit version so there's separate R64.app. I am sorry about that - renaming the subject of this discussion to something more appropriate. >> I say installing R in 64-bit Linux and launching R GUI app > > There is no such thing on Linux. R.app exists only on OS X. Windows has Rgui > and it has two of them as well (32-bit and 64-bit) and they also come with > two separate icons, same as on OS X. Go figure :). Sorry for the mental shortcut, I know that there's no official R GUI app for Linux, but there's "R --gui=". Still on Linux you won't know any arch distinction exists unless you dig deeper into command line params. On Mac you do, because hey, there are TWO apps installed by the packager. Which once shall I use then? Which one's better? :P > Because this decision is made at install time depending on your OS X version > - it is 32-bit for Leopard, for example. Whether this is the right thing to > do is up for discussion (when installed from source you'll get the last > installed architecture). R.app doesn't need to make that decision, since it > is always 32-bit - easy. No it is not, because the convention is violated. If you run Activity Monitor.app on SL or Lion you will see most of apps are 64-bit, but they don't have any "64" suffix or whatsoever. Such internals are hidden from the Mac user. Apple has decided so, and I do agree with them (even I do not agree with them in many other cases ;)), an average user does not need to know about CPU architectures, so it is OS that should choose for him, leaving of course some way to change that decision. > I hope that helps understanding it a bit better. If not, please, consider > learning more about R. I did one thing wrong, started this discussion with wrong subject bringing a suggestion that R is somehow incomplete. I am very sorry about that, I had no indention to suggest anything like that. Yes I do learn R, and I find it very mature and advanced software. I do have also MatLab and Mathematica (university licenses) here but I find R superior to them, as it less cluttered, better optimized and what's more important more consistent. Best regards, -- Adam _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
