[Rd] R, Wine, and multi-threadedness.

[Marc Schwartz (via MN)]

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