Skip to content

Bug in R evaluating a huge instruction (PR#14096)

7 messages · Duncan Murdoch, Simon Urbanek, Jean Couteau +1 more

#
Thanks for your time Duncan,

I join here the instruction that is not correct, hoping that might help 
you. The file is encoded in utf-8 so you should not have any problem 
reading it.

I doubt to that it is an R bug too, but with all my tests i am less and 
less sure of that.

Best regards,
Jean Couteau
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: morrisError.R
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20091201/091d2a71/attachment.pl>
#
Hello,

Since we don't have the morris function, I have tested using this one:

 > morris <- function(...) lapply(list(...), str )

If I just copy and paste into the console, R waits for more input, but 
if I parse the file, it is fine:

 > eval( parse( "morrisError.R" ) )
  NULL
  chr [1:86] "PecheAmateurs d?cembre.proportionMetier" ...
  num 10
List of 3
  $ type     : chr "oat"
  $ levels   : num [1:86] 5 5 5 5 5 5 5 5 5 5 ...
  $ grid.jump: num [1:86] 2 2 2 2 2 2 2 2 2 2 ...
  num [1:86] 0 0 0 11 10 12 0.06 10 11 0 ...
  num [1:86] 1 1 1 15 14 16 0.09 14 15 2 ...


Also fine if I source the file:

 > a<-morris(model=NULL,factors=c("PecheAmateurs 
d?cembre.proportionMetier","PechePetitMetierMer 
mai.proportionMetier","PecheAmateurs mai.proportionMet ..." ... [TRUNCATED]
  NULL
  chr [1:86] "PecheAmateurs d?cembre.proportionMetier" ...
  num 10
List of 3
  $ type     : chr "oat"
  $ levels   : num [1:86] 5 5 5 5 5 5 5 5 5 5 ...
  $ grid.jump: num [1:86] 2 2 2 2 2 2 2 2 2 2 ...
  num [1:86] 0 0 0 11 10 12 0.06 10 11 0 ...
  num [1:86] 1 1 1 15 14 16 0.09 14 15 2 ...


I think the limit imposed by the R_ParseBuffer function (in gram.y) is 
1024 characters.

Romain
On 12/01/2009 06:50 AM, Jean Couteau wrote:

  
    
#
On 01/12/2009 12:50 AM, Jean Couteau wrote:
I have no problem sourcing that file, but I do get an error if I try to 
cut and paste it, because it's a single line of 4890 characters, and 
that's too long.  So this is an R limitation, but it's one with an easy 
workaround:  just add some line breaks into your source.

Duncan Murdoch
#
Thank you very much for your input Duncan and Romain.

I will try to do what you are advising. The R instruction is generated 
from java using jri (and an abstraction layer we built upon it : 
nuiton-j2r), i will try add this limitation to nuiton-j2r so that it 
split the instruction if it is too long.

Best regards,
Jean
Duncan Murdoch wrote:
#
On Dec 2, 2009, at 2:27 , Jean Couteau wrote:

            
FWIW the restriction is only on the console input - if you send it  
directly, there is no limit (I have never heard of nuiton-j2r but if  
you use rJava to interface from Java to R there is no limit - the  
string you parse+evaluate can be of any length).

Cheers,
Simon
#
Hi Simon,

nuiton-j2r is in fact an abstraction layer to rjava or rserve so that it 
can switch between one or other implementation using simple 
configuration (http://maven-site.nuiton.org/nuiton-j2r/ sorry but this 
is in french). And in fact I encounter the problem using it.

What is done is basically creating the R instruction from java and 
sending it to R using the eval method from the Rengine object (as we use 
jri in this specific application). The R instruction should create an 
object a of class morris, and I try then to get back the a$X object (the 
X item of the morris object) but I get back a null object without any 
reason, that is why I tried copying the instruction directly in R and 
thus getting this problem.

So that is strange if you say that there is no limit using rjava/jri.

Cheers,
Jean
#
Hi,

You really should use the REngine API, which lets you control jri and 
Rserve using the same api. See the org.rosuda.REngine package in 
http://www.rforge.net/org/docs/

Either wayn, I have no problem evaluating the problematic string with 
both apis.

Romain
On 12/02/2009 03:26 PM, Jean Couteau wrote: