From edd at debian.org  Fri Aug 20 17:59:01 2010
From: edd at debian.org (Dirk Eddelbuettel)
Date: Fri, 20 Aug 2010 10:59:01 -0500
Subject: [Rd] C or Java code generation
In-Reply-To: <1282317952173-2332632.post@n4.nabble.com>
References: <AANLkTikMyRzcDHtCSb9f31v5wnN+FLrbQXAwRDg7ui1E@mail.gmail.com>
	<4C6D0BC2.7070906@yandex.ru>
	<AANLkTi=X-NfgGf3czS9t4LwUKBrUne7=1r+BO7soacEM@mail.gmail.com>
	<19565.13345.692185.626415@max.nulle.part>
	<4C6D3A53.5070808@yandex.ru>
	<19565.21908.102685.183781@max.nulle.part>
	<4C6E3DA0.7010005@yandex.ru> <4C6E4049.4090800@dbmail.com>
	<1282316530615-2332606.post@n4.nabble.com>
	<19566.40074.624066.821704@max.nulle.part>
	<1282317952173-2332632.post@n4.nabble.com>
Message-ID: <19566.42565.331336.955411@max.nulle.part>


On 20 August 2010 at 08:25, Sharpie wrote:
| My apologies Dirk, I phrased that badly.  

No worries.
 
| What I ment is that RInside provides an interface by which the C++ program
| can interact with R.  Essentially, what the OP would gain from RInside is
| that he would not have to use DCOM.

Apart from the fact (that I alluded to earlier) that 
  a) RInside does not build with the windoze toolchain but 
  b) requires Rtools by Duncan M, and 
  c) as of late builds but segfaults when running on Windoze.

So in short he is not helped at all unless he changes platforms. C'est la vie.


On 20 August 2010 at 11:39, Simon Urbanek wrote:
| I fear not: RInside, Rserve, R[D]COM, JRI, ... all embed R which was that his point, rightly so. 

I know next to nothing about JRI and RwhateverCOM so I will skip those. But I
have been in pushing for adoption of Rserve in different places and as early
as 2003/2004 as I am a big, big fan of Rserver (as well as Debian maintainer).  

However, RInside is much different in that it is a) in-process and b) endowed
with the richer Rcpp interface that Romain and I have been building.  So in
that sense this is not a comparison to me apart from the obvious fact that
both use R in an embedded fashion.
 
| There is no way I know of to turn R code into something that can run on its own without R present (save for a tiny subset of Rmath).

You seem to have missed that I made that same point, and stressed it as a
good one.  Not of the aforementioned technologies are meant to hide R or
permit deployment without it.

Dirk

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com



[Rd] C or Java code generation
Dirk Eddelbuettel