Re: R.pl hangs in debian linux

Dear Bob,

On Fri, 15 Nov 2013 00:33:44 -0600
"Bob Ly" <[email protected]> wrote:

> Good Day Nicos,
> 
> My apologies for a late response. I tried pack(real). This was the  
> error message I got.
> 
> ERROR: /usr/local/lib/swipl-6.5.2/pack/real/prolog/real.pl:1086:
> 	'$open_shared_object'/3: libR.so: cannot open shared object file: No  
> such file or directory
> Warning: /usr/local/lib/swipl-6.5.2/pack/real/prolog/real.pl:1086:
> 	Goal (directive) failed: real:initialization(start_r,now)
> 
	real connects to the R library  rather than the executable.
	So you need (1) to have libR.so, and (2) your system must be able to find it at run time.

	On linux if you install from r-base I think libR.so usually goes to a visible place (in recent distros).
	If you install R from sources you need to compile with
		./configure --enable-R-shlib
	Once you locate your libR.so and if that is not in the places linux is looking for libraries,
	you need to add the directory to LD_LIBRARY_PATH environment variable.

> But I got R.pl to work. If I am understanding correctly the main  
> difference between R.pl and real.pl is real.pl can interchange data  
> between the two programs? Whereas, R.pl is more like a wrapper call  
> around R to manipulate data?
> 
	R.pl starts an R executable as a slave (to SWI) and communicates through the i/o streams.
	so,
	x <- c(1,2,3) 
	will be written on the stream prolog has associated with the R input stream. 
	Communicating via the i/o streams is both inefficient and flaky. also there is a 
	limit on the length of expressions you can pass to R and back.

	real starts an R shared object and communicates with it via the C interface.
	so,
	x <- c(1,2,3)
	will create/erase x and assign to it the vector the values 1,2,3 by walking the c/3 term (or corresponding list) in C.
	doing this via C is far more resilient, efficient and has no inherent size limit.
	
Hope it helps.

Nicos Angelopoulos
---
http://stoics.org.uk/~nicos/