Hin-Tak Leung
2007-Jan-10 19:29 UTC
[Rd] wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?
Does anybody (most probably the core team) know if there is any difference in how the official 2.4.0 and 2.4.1 binaries are built? Problem is, 2.4.0 loads with the wine (I tried a few recent versions, and also used 2.3.x under wine from time to time), but 2.4.1 won't. Thanks. Hin-Tak Leung
Duncan Murdoch
2007-Jan-10 19:59 UTC
[Rd] wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?
On 1/10/2007 2:29 PM, Hin-Tak Leung wrote:> Does anybody (most probably the core team) know if there is > any difference in how the official 2.4.0 and 2.4.1 binaries are > built? > > Problem is, 2.4.0 loads with the wine (I tried a few recent > versions, and also used 2.3.x under wine from time to time), > but 2.4.1 won't.Yes, there were changes to the MinGW run-time library between those two releases. See http://www.murdoch-sutherland.com/Rtools/. If you can be more specific about the problem, it's possible the Wine or MinGW people could fix it. Duncan Murdoch
Hin-Tak Leung
2007-Jan-12 20:05 UTC
[Rd] Java on 64-bin Linux [was: cross tools (was Re: wine and build difference between R.2.4.0 and R 2.4.1 windows binaries?)]
Simon Urbanek wrote:> > On Jan 12, 2007, at 1:31 PM, Hin-Tak Leung wrote: > >> Prof Brian Ripley wrote: >>> On Fri, 12 Jan 2007, Simon Urbanek wrote: >>>> >>>> On Jan 12, 2007, at 7:31 AM, Hin-Tak Leung wrote: >>>> >>>>> I do use Java, just not in relation to R - it has been a while >>>>> since I played with SJava. Sun's JDK (32-bit) has been working >>>>> consistently. >>>>> On FC5 x86_64 the default gcj-based JRE was a bit funny, but since >>>>> upgraded to FC6, I found the gcj-based JRE on x86_64 can run >>>>> haploview (http://www.broad.mit.edu/mpg/haploview/) reasonably >>>>> well. If you want 64-bit R working with a 64-bit JRE, the gcj-based >>>>> jre seems to be the only route. >>>> >>>> For the record, rJava and JRI work fine with Sun's Java 1.6 on >>>> 64-bit systems (fine being defined by the fact that JGR works :)). >>>> JGC-based JRE is still quite buggy on both 32 and 64-bit machines as >>>> far as we can tell, but for non-GUI task it seems to work. However, >>>> I don't think this is what Brian has in mind ... >>> Sun's Java 1.6 does not run JGR or rJava on our FC5 Opteron boxes >>> unfortunately, which is behind my comment. (It gives the same >>> problems as 1.5.0_x, which Simon also had) An essentially identical >>> i686 installation (same set of FC5 RPMs) does run rJava etc. We did >>> manage to get a Blackdown version of Java 1.4.2 to start rJava, but >>> it soon crashed. >> >> haploview is GUI and it does run alright-ish under the gcj-based jre >> under FC6. I know gcj is not as mature as blackdown or Sun's ; but >> given Sun's is 32-bit only, and gcj is shipped with FC6... and yes, >> gcj on FC5 was a bit funny. >> > > I'm running everything on Debian etch (=testing) and they are usually up > to date. GIJ/GCJ/GNU classpath have made astonishing progress, but they > are still not ready for the prime-time. Swing & co. are just too > complex to have a bullet-proof implementation - even Sun took years to > come even close to an usable implementation ..I don't intend to start a distribution war, but I found Debian testing too *conservative* during my 1-week trial of Debian a couple of years ago, and opted for Debian unstable almost right away. (and I try to avoid Debian/Debian hang-outs - too many egos and bickering and just not getting anything done). Debian stable is a joke for a fossil. As for "not ready for prime-time" and the other comments - nothing is ready for prime time if nothing ever get tested/used. I only disguish between usable and not-usable. FWIW, I work with some people who describe R as not ready for prime-time as well :-P. And you can also discard Wine as "windows is too complex to have a bullet-proof implementation, even Microsoft took years to come even close to an usable implementation"... Given that JNI with GCJ on FC6 does work with a reasonably complex piece of software (gridengine.sunsource.net), and the GUI components does work with a fairly graphically-rich piece of software (haploview), I'd say it is worth giving gcj is try. After all, nothing is ready for prime-time if nothing ever get used/tested - and it applies as much to GCJ as it is for R. Just my 2-cents. Hin-Tak