oid parsing the same script
again each time it is evaluated. Does the engine recognize previously
parsed scripts (like oracle does for SQL queries)?
I interested to hear your thoughts on my concerns and whether you think
R would work in this architecture.
kind regards,
Erik van Zijst
--
And on
Simon Urbanek wrote:
>
> On Dec 8, 2006, at 9:51 AM, Erik van Zijst wrote:
>
>> 2. R's native C-api
>> [http://cran.r-project.org/doc/manuals/R-exts.html#The-R-API] does not
>> separate parsing from evaluation.
N.B. above I mistakenly referred to chapter
Hi All,
My problem is about parallel execution of R-scripts. My platform is linux.
A program that is written in C needs to execute multiple R-scripts
simultaneously. The C program makes use of multi-threading. Each thread
must initiate the execution of one script. Performance is very important.
Hello all,
I am using R 2.4.0 and SJava 0.69-0 on linux.
I am not able to install SJava on R. The following errors appear when
installing:
...
** R
** inst
WARNING: use of install..R is no longer supported
** preparing package for lazy loading
Creating a new generic function for "merge" in "SJa
Byron Ellis wrote:
> Short Answer: There isn't one.
I was afraid so. Thanks for confirming.
> On 1/3/07, Erik van Zijst <[EMAIL PROTECTED]> wrote:
>
>> Hi All,
>>
>> My problem is about parallel execution of R-scripts. My platform is
>> linux.
&
Vladimir Dergachev wrote:
> On Wednesday 03 January 2007 3:47 am, Erik van Zijst wrote:
>
>>Appearantly the R C-API does not provide a mechanism for parallel
>>execution..
>>
>>It is preferred that the solution is not based on multi-processing (like
>>C/
Hi Martin,
Your approach of bolting a webservices layer on top of R is a really
nice (and quite natural) thing to do.
I appreciate your early announcement in response to our thread and I'd
very much like to be kept in the loop of future announcements, so please
add my address to your list.
As yo
Jeffrey Horner wrote:
> I haven't looked at RServe in awhile, but I think that it fires up an R
> interpreter in response to a client request and then sticks around for
> the same client to serve it additional requests. The question is how
> does it manage all the R interpreters with varying dem
Vladimir Dergachev wrote:
>>Using pipes or shared memory to pass things around to other processes on
>>the same box is very fast indeed, but if we base our design around
>>something like RServe which uses TCP it could be significantly slower.
>>Our R-based system will be running scripts in response
