On Thu, 2005-10-13 at 17:19 +0100, Prof Brian Ripley wrote: > On Thu, 13 Oct 2005, Marc Schwartz (via MN) wrote: > > > On Thu, 2005-10-13 at 16:45 +0100, Hin-Tak Leung wrote: > >> Prof Brian Ripley wrote: > >> <snipped> > >>>> Now, the interesting questions are: (1) is Atlas multi-threaded on > >>>> *every* platform, or more specifically, on Windows?, > >>> > >>> > >>> By default it is not multi-threaded on any platform, and we have not > >>> succeeded in compiling a multi-threaded version on Windows except by > >>> using Cygwin extensions (i.e. not actually on Windows). > >> > >> Thanks for the explanations. As I said, my main interests in running > >> R under Wine is mostly about having a GUI, but the multi-threading > >> possibility is an interesting discussion; also re-compiling > >> the whole lot (either for win32 or linux) just for the *possibility* of > >> speeding up is a bit painful, so having drop-in dll replacement > >> (or a shared-library replacement) for trying-out sounds rather attractive. > > > > Sorry for jumping in here and no disrespect intended to anyone, but I am > > confused relative to the desire and benefits of running R under Wine on > > Linux simply for the sake of using the RGui.exe menus, when there are > > other substantive tradeoffs relative to running R natively on Linux, as > > Prof. Ripley has noted. > > One reason for doing so is to be able to prepare for teaching in a Windows > environment: I believe this is why it is mentioned in the FAQ. (I > personally test on the machine to be used just to be sure things work.)
Good point. I had not considered that, not being in a teaching environment. Running on a laptop, I always have a known machine with me, even when doing presentations in front of a group/audience. > > The one "advantage" that I had seen some time ago, was the possibility > > of being able to generate metafile graphics for inclusion with MS Office > > apps by using the native Windows libs (in a dual-boot scenario as I > > recall). However other substantively better options for generating high > > quality graphics have been proposed and discussed here frequently. > > I am not 100% convinced that they are `substantively better' in all > environments, and I still do that sometimes. No disagreement if there is a specific need for this. Where that need is present, this is a better solution than using the Linux native libEMF functionality, which is problematic as has been discussed in those same threads. I was more focused (and confused) on the Rgui.exe menus as the principal justification for taking this approach, but again, perhaps I am lacking context. Marc ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
