[Rd] what's R save terminal flag?

[dma]

When I save a R object through RConnection, how to determine when the data is
end in the RConnction's other side?

I print the data as integer. It seams the data was end with -2. Is there any
official document about that?

Thanks Dma


--
View this message in context: 
http://r.789695.n4.nabble.com/what-s-R-save-terminal-flag-tp3497940p3497940.html
Sent from the R devel mailing list archive at Nabble.com.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Curry: proposed new functional programming, er, function.

[Hadley Wickham]

> Thanks, Hadley.  This (i.e., different ways to prepare curry) is quite 
> instructive to me.

The following update makes the generated function look a little nicer
if you pass in the name of a function:

Curry <- function(FUN, ...) {
  args <- match.call(expand.dots = FALSE)$...
  args$... <- as.name("...")

  if (is.name(FUN)) {
fname <- FUN
  } else if (is.character(FUN)) {
fname <- as.name(FUN)
  } else {
fname <- as.name("FUN")
  }
  curry_call <- as.call(c(list(fname), args))
  eval(call("function", as.pairlist(alist(... = )), curry_call))
}

And it seems to work ok in terms of preserving evaluation (I can't how
it could be any different to making the anonymous function yourself,
unless I've missed something subtle with environments and scoping)

> hadley <- 1:10
> plothadley <- Curry("plot", x = hadley)
> plothadley
function (...)
plot(x = hadley, ... = ...)

> plothadley()
> plothadley(runif(10))

The only (minor) problem is that I couldn't figure out how to
construct the interior call to yield plot(x = hadley, ...)

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Curry: proposed new functional programming, er, function.

[Hadley Wickham]

> And it seems to work ok in terms of preserving evaluation (I can't how
> it could be any different to making the anonymous function yourself,
> unless I've missed something subtle with environments and scoping)

Which indeed I have.  Hmmm, need to think about this more.

Hadley


-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Curry: proposed new functional programming, er, function.

[Hadley Wickham]

On Thu, May 5, 2011 at 8:25 AM, Hadley Wickham  wrote:
>> And it seems to work ok in terms of preserving evaluation (I can't how
>> it could be any different to making the anonymous function yourself,
>> unless I've missed something subtle with environments and scoping)
>
> Which indeed I have.  Hmmm, need to think about this more.

Ok, next version.  To follow the usual rules of function scope, we
need to make sure the environment of the function is set to the
environment in which it is created.

Curry <- function(FUN, ...) {
  args <- match.call(expand.dots = FALSE)$...
  args$... <- as.name("...")

  env <- parent.frame()

  if (is.name(FUN)) {
fname <- FUN
  } else if (is.character(FUN)) {
fname <- as.name(FUN)
  } else if (is.function(FUN)){
fname <- as.name("FUN")
env$FUN <- FUN
  } else {
stop("FUN not function or name of function")
  }
  curry_call <- as.call(c(list(fname), args))

  f <- eval(call("function", as.pairlist(alist(... = )), curry_call))
  environment(f) <- env
  f
}

But I've probably forgotten something else.  Hopefully Luke will chime
in if I'm proceeding down a path that can never be made to work
completely correctly.

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] what's R save terminal flag?

[Ben Bolker]

dma  hotmail.com> writes:

> 
> When I save a R object through RConnection, how to determine when the data is
> end in the RConnction's other side?
> 
> I print the data as integer. It seams the data was end with -2. Is there any
> official document about that?
> 
> Thanks Dma
> 

  Please pick *either* r-help *or* Stack Overflow to post your question:
don't cross-post. 
()

  As always, reproducible examples are helpful: please see the R-help
posting guide.

  cheers
Ben Bolker

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Curry: proposed new functional programming, er, function.

[Gabor Grothendieck]

On Thu, May 5, 2011 at 9:32 AM, Hadley Wickham  wrote:
> On Thu, May 5, 2011 at 8:25 AM, Hadley Wickham  wrote:
>>> And it seems to work ok in terms of preserving evaluation (I can't how
>>> it could be any different to making the anonymous function yourself,
>>> unless I've missed something subtle with environments and scoping)
>>
>> Which indeed I have.  Hmmm, need to think about this more.
>
> Ok, next version.  To follow the usual rules of function scope, we
> need to make sure the environment of the function is set to the
> environment in which it is created.
>
>    Curry <- function(FUN, ...) {
>      args <- match.call(expand.dots = FALSE)$...
>      args$... <- as.name("...")
>
>      env <- parent.frame()
>
>      if (is.name(FUN)) {
>        fname <- FUN
>      } else if (is.character(FUN)) {
>        fname <- as.name(FUN)
>      } else if (is.function(FUN)){
>        fname <- as.name("FUN")
>        env$FUN <- FUN
>      } else {
>        stop("FUN not function or name of function")
>      }
>      curry_call <- as.call(c(list(fname), args))
>
>      f <- eval(call("function", as.pairlist(alist(... = )), curry_call))
>      environment(f) <- env
>      f
>    }
>
> But I've probably forgotten something else.  Hopefully Luke will chime
> in if I'm proceeding down a path that can never be made to work
> completely correctly.
>

There is some question of whether it should default to the current
environment or the original function's environment.  If the curried
function were regarded as part of a new object whose environment is
the current environment then having the current environment (i.e.  the
object's environment) makes sense but if its regarded purely as an
operation on the original function then the original function's
environment makes more sense.  In any case, an envir= argument to
allow the user to specify it would be desirable.  Perhaps it could
specify the environment to assign (or if a logical or keyword were
specified it would indicate which of the two possibilities just
mentioned to use to make the common choices easy to specify).


-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] problem with location of libraries 64-bit (opensuse)

[Detlef Steuer]

Dear list, 

there seems to be a problem with the standard location of R´s 64-bit libs
at least under openSUSE.

I had two user questions regarding the compilation of rpy2 for 64-bit systems.
Personally I don`t know rpy2 but maybe someone on this list can decide if
the mistake lies on R`s side or on rpy2´s side or in between.

R-devel is installed in these cases, I asked. Latest R-base or R-patched is 
used.

The following problem occurs (user report):

---
> Python 2.7 (r27:82500, Aug 07 2010, 16:54:59) [GCC] on linux2
> Type "help", "copyright", "credits" or "license" for more information.  
> >>> import rpy2.robjects as robjects  
> Traceback (most recent call last):
> File "", line 1, in 
> File "/usr/local/lib64/python2.7/site-packages/rpy2/robjects/__init__.py",
> line 12, in  import rpy2.rinterface as rinterface
> File
> "/usr/local/lib64/python2.7/site-packages/rpy2/rinterface/__init__.py",
> line 66, in  from rpy2.rinterface.rinterface import *
> ImportError: /usr/lib64/R/lib/libRlapack.so: undefined symbol:
> _gfortran_concat_string
--


So there are difficulties with  lapack/fortran libs.

An older version of apparently the same error can be found here:
http://www.mail-archive.com/animov@faunalia.it/msg00311.html

Another user reported the following:


After installing the R devel version with Yast on the 11.4 64 system there  
was a link at this location :

/usr/lib64/libRlapack.so

and the actual file was here :

/usr/lib64/R/lib/libRlapack.so


I compiled R from source :

./configure --prefix=/usr --enable-R-shlib
make
make install

The make install step did not copy the new *.so files to /usr/lib64/R/lib
therefore I manually copied the new libRlapack.so , libR.so and libRblas.so

After that the python rpy2 library loaded and all was ok.

I hope this will help you to identify this issue .
--

Because he had to manually copy over libs after installing from source maybe 
there is an easy improvement on the side of R`s installation routines? Some 
ldconfig call missing or something? 
Or is this an opensuse specific problem?

Any hint appreciated.

Detlef


signature.asc
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] problem with location of libraries 64-bit (opensuse)

[Simon Urbanek]

Detlef,

On May 5, 2011, at 10:50 AM, Detlef Steuer wrote:

> Dear list, 
> 
> there seems to be a problem with the standard location of R´s 64-bit libs
> at least under openSUSE.
> 
> I had two user questions regarding the compilation of rpy2 for 64-bit systems.
> Personally I don`t know rpy2 but maybe someone on this list can decide if
> the mistake lies on R`s side or on rpy2´s side or in between.
> 
> R-devel is installed in these cases, I asked. Latest R-base or R-patched is 
> used.
> 
> The following problem occurs (user report):
> 
> ---
>> Python 2.7 (r27:82500, Aug 07 2010, 16:54:59) [GCC] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.  
> import rpy2.robjects as robjects  
>> Traceback (most recent call last):
>> File "", line 1, in 
>> File "/usr/local/lib64/python2.7/site-packages/rpy2/robjects/__init__.py",
>> line 12, in  import rpy2.rinterface as rinterface
>> File
>> "/usr/local/lib64/python2.7/site-packages/rpy2/rinterface/__init__.py",
>> line 66, in  from rpy2.rinterface.rinterface import *
>> ImportError: /usr/lib64/R/lib/libRlapack.so: undefined symbol:
>> _gfortran_concat_string
> --
> 
> 
> So there are difficulties with  lapack/fortran libs.
> 

Yes, libgfortran is not loaded. You'll have to look at ldd output to see why - 
see further down.


> An older version of apparently the same error can be found here:
> http://www.mail-archive.com/animov@faunalia.it/msg00311.html
> 
> Another user reported the following:
> 
> 
> After installing the R devel version with Yast on the 11.4 64 system there  
> was a link at this location :
> 
> /usr/lib64/libRlapack.so
> 
> and the actual file was here :
> 
> /usr/lib64/R/lib/libRlapack.so
> 
> 
> I compiled R from source :
> 
> ./configure --prefix=/usr --enable-R-shlib
> make
> make install
> 
> The make install step did not copy the new *.so files to /usr/lib64/R/lib
> therefore I manually copied the new libRlapack.so , libR.so and libRblas.so
> 
> After that the python rpy2 library loaded and all was ok.
> 
> I hope this will help you to identify this issue .

This shows that rpy2 doesn't setup up the environment correctly (see the R 
script for the necessary settings). libR* are NOT supposed to the in /usr/lib64 
- it is a bad hack and very dangerous (programs may pick the incorrect R 
libraries). Given that the setup is already messed up it's hard to tell what 
causes the gfortran problem. I don't have any SuSE around (they all died out 
long time ago) but to illustrate how things are supposed to work let's have a 
look at Debian (R installed from sources):

Inside R/lib there are the internal R libraries, again, they are NOT supposed 
to be at the system level:
urbanek@ix:/usr/local/R/2.13/lib/amd64$ ls libR*
libRblas.so  libRlapack.so  libR.so

so use ldd to see what they load:

urbanek@ix:/usr/local/R/2.13/lib/amd64$ ldd libRlapack.so 
linux-vdso.so.1 =>  (0x7fff602fa000)
libRblas.so => not found
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7fbc5c3b4000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7fbc5c197000)
libc.so.6 => /lib/libc.so.6 (0x7fbc5be36000)
librt.so.1 => /lib/librt.so.1 (0x7fbc5bc2e000)
/lib64/ld-linux-x86-64.so.2 (0x7fbc5c94d000)

urbanek@ix:/usr/local/R/2.13/lib/amd64$ ldd libRblas.so 
linux-vdso.so.1 =>  (0x7fff27bff000)
libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x7f9662988000)
libm.so.6 => /lib/libm.so.6 (0x7f9662706000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x7f96624f8000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7f96622dc000)
libc.so.6 => /lib/libc.so.6 (0x7f9661f7b000)
librt.so.1 => /lib/librt.so.1 (0x7f9661d72000)
/lib64/ld-linux-x86-64.so.2 (0x7f9662eb1000)

so as you see, lapack links to blas which in turn links to gfortran. So if you 
load lapack you'll get gfortran vis blas. In your setup you are missing the 
link to gfortran for one reason or another. So check your setup with ldd to see 
why. I think it's highly likely that rpy2 is to blame, because R itself would 
not run if the fault would be in R.

Cheers,
Simon


> --
> 
> Because he had to manually copy over libs after installing from source maybe 
> there is an easy improvement on the side of R`s installation routines? Some 
> ldconfig call missing or something? 
> Or is this an opensuse specific problem?
> 
> Any hint appreciated.
> 
> Detlef
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] matrix not positive definite (while it should be)

[Arthur Charpentier]

I do have some trouble with matrices. I want to build up a covariance matrix
with a hierarchical structure). For instance, in dimension n=10, I have two
subgroups (called REGION).

NR=2; n=10
CORRELATION=matrix(c(0.4,-0.25,
 -0.25,0.3),NR,NR)
REGION=sample(1:NR,size=n,replace=TRUE)
R1=REGION%*%t(rep(1,n))
R2=rep(1,n)%*%t(REGION)
SIGMA=matrix(NA,n,n)

for(i in 1:NR){
for(j in 1:NR){
SIGMA[(R1==i)&(R2==j)]=CORRELATION[i,j]
}}

If I run quickly some simulations, I build up the following matrix

> CORRELATION
  [,1]  [,2]
[1,]  0.40 -0.25
[2,] -0.25  0.30
> REGION
 [1] 2 2 1 1 2 1 2 1 1 2
> SIGMA
   [,1]  [,2]  [,3]  [,4]  [,5]  [,6]  [,7]  [,8]  [,9] [,10]
 [1,]  0.30  0.30 -0.25 -0.25  0.30 -0.25  0.30 -0.25 -0.25  0.30
 [2,]  0.30  0.30 -0.25 -0.25  0.30 -0.25  0.30 -0.25 -0.25  0.30
 [3,] -0.25 -0.25  0.40  0.40 -0.25  0.40 -0.25  0.40  0.40 -0.25
 [4,] -0.25 -0.25  0.40  0.40 -0.25  0.40 -0.25  0.40  0.40 -0.25
 [5,]  0.30  0.30 -0.25 -0.25  0.30 -0.25  0.30 -0.25 -0.25  0.30
 [6,] -0.25 -0.25  0.40  0.40 -0.25  0.40 -0.25  0.40  0.40 -0.25
 [7,]  0.30  0.30 -0.25 -0.25  0.30 -0.25  0.30 -0.25 -0.25  0.30
 [8,] -0.25 -0.25  0.40  0.40 -0.25  0.40 -0.25  0.40  0.40 -0.25
 [9,] -0.25 -0.25  0.40  0.40 -0.25  0.40 -0.25  0.40  0.40 -0.25
[10,]  0.30  0.30 -0.25 -0.25  0.30 -0.25  0.30 -0.25 -0.25  0.30

Here are eigenvalues (or at least the lower ones)

> min(eigen(SIGMA)$values)
[1] -2.109071e-17
> min(eigen(CORRELATION)$values)
[1] 0.09504902

theoretically, it should be 0 for SIGMA, but here it is not the case.
The problem here is that here, I cannot generate a Gaussian random vector
with that specific covariance matrix, since Cholesky does not work...

> library(mnormt)
> RES=rmnorm(n,mean=MU,varcov=SIGMA)
Error in chol.default(varcov) :
  the leading minor of order 4 is not positive definite

any suggestions ? perhaps a better way of building my covariance matrix ? or
another way of generating a random vector with that specific covariance
matrix ?

Thanks for your help

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] median and data frames

[Joshua Ulrich]

On Fri, Apr 29, 2011 at 9:25 AM, Martin Maechler
 wrote:
>> Paul Johnson 
>>     on Thu, 28 Apr 2011 00:20:27 -0500 writes:
>
>    > On Wed, Apr 27, 2011 at 12:44 PM, Patrick Burns
>    >  wrote:
>    >> Here are some data frames:
>    >>
>    >> df3.2 <- data.frame(1:3, 7:9)
>    >> df4.2 <- data.frame(1:4, 7:10)
>    >> df3.3 <- data.frame(1:3, 7:9, 10:12)
>    >> df4.3 <- data.frame(1:4, 7:10, 10:13)
>    >> df3.4 <- data.frame(1:3, 7:9, 10:12, 15:17)
>    >> df4.4 <- data.frame(1:4, 7:10, 10:13, 15:18)
>    >>
>    >> Now here are some commands and their answers:
>
>    >>> median(df4.4)
>    >> [1]  8.5 11.5
>    >>> median(df3.2[c(1,2,3),])
>    >> [1] 2 8
>    >>> median(df3.2[c(1,3,2),])
>    >> [1]  2 NA
>    >> Warning message:
>    >> In mean.default(X[[2L]], ...) :
>    >>  argument is not numeric or logical: returning NA
>    >>
>    >>
>    >>
>    >> The sessionInfo is below, but it looks
>    >> to me like the present behavior started
>    >> in 2.10.0.
>    >>
>    >> Sometimes it gets the right answer.  I'd
>    >> be grateful to hear how it does that -- I
>    >> can't figure it out.
>    >>
>
>    > Hello, Pat.
>
>    > Nice poetry there!  I think I have an actual answer, as opposed to the
>    > usual crap I spew.
>
>    > I would agree if you said median.data.frame ought to be written to
>    > work columnwise, similar to mean.data.frame.
>
>    > apply and sapply  always give the correct answer
>
>    >> apply(df3.3, 2, median)
>    > X1.3   X7.9 X10.12
>    > 2      8     11
>
>    [...]
>
> exactly
>
>    > mean.data.frame is now implemented as
>
>    > mean.data.frame <- function(x, ...) sapply(x, mean, ...)
>
> exactly.
>
> My personal oppinion is that  mean.data.frame() should never have
> been written.
> People should know, or learn, to use apply functions for such a
> task.
>
> The unfortunate fact that mean.data.frame() exists makes people
> think that median.data.frame() should too,
> and then
>
>  var.data.frame()
>   sd.data.frame()
>  mad.data.frame()
>  min.data.frame()
>  max.data.frame()
>  ...
>  ...
>
> all just in order to *not* to have to know  sapply()
> 
>
> No, rather not.
>
> My vote is for deprecating  mean.data.frame().
>
> Martin
>

I agree.  However, sd() isn't currently (as of R-2.13.0) generic and
it operates by column for matrix and data.frame objects, so it behaves
a bit more like mean() and is similarly inconsistent from the other
listed functions.  I have no input on how this should be handled, but
thought it may be worth addressing.

Best,
--
Joshua Ulrich  |  FOSS Trading: www.fosstrading.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] problem with location of libraries 64-bit (opensuse)

[Detlef Steuer]

Simon,

thank you very much for the detailed answer.

> This shows that rpy2 doesn't setup up the environment correctly (see the R 
> script for the necessary settings). libR* are NOT supposed to the in 
> /usr/lib64 - it is a bad hack and very dangerous (programs may pick the 
> incorrect R libraries). Given that the setup is already messed up it's hard 
> to tell what causes the gfortran problem. 


Ok, this mess up is easily identified. In my spec file I link
$libdir/R/lib/libRblas.so to $libdir/libRblas.so and the same for libR
and liblapack. Hmm. It works that way for ages, I can`t even vaguely
remember when and why I introduced that. 
Now I`ve build  R-patched with these links removed. 
At least "here it works". May be that cures rpy2, too.

Thx again
Detlef

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Recursive objects

[Steve Lianoglou]

On Wed, May 4, 2011 at 9:24 AM, Barry Rowlingson
 wrote:
> On Wed, May 4, 2011 at 2:21 PM, Hadley Wickham  wrote:
>
>> Any hints as to what to search for?
>
>  For recursive objects, search for recursive objects.

Awesome :-)

And completely OT but strangely related -- in case you've never
stumbled on this gem:

google for "recursion" and look for Google's "Did you mean" suggestion ...

-- 
Steve Lianoglou
Graduate Student: Computational Systems Biology
 | Memorial Sloan-Kettering Cancer Center
 | Weill Medical College of Cornell University
Contact Info: http://cbio.mskcc.org/~lianos/contact

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Recursive objects

[David Winsemius]

On May 5, 2011, at 1:07 PM, Steve Lianoglou wrote:


On Wed, May 4, 2011 at 9:24 AM, Barry Rowlingson
 wrote:
On Wed, May 4, 2011 at 2:21 PM, Hadley Wickham   
wrote:



Any hints as to what to search for?


 For recursive objects, search for recursive objects.


Awesome :-)

And completely OT but strangely related -- in case you've never
stumbled on this gem:

google for "recursion" and look for Google's "Did you mean"  
suggestion ...


Man  ... sometimes I am so slow!



--
Steve Lianoglou
Graduate Student: Computational Systems Biology
 | Memorial Sloan-Kettering Cancer Center
 | Weill Medical College of Cornell University
Contact Info: http://cbio.mskcc.org/~lianos/contact

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


David Winsemius, MD
West Hartford, CT

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] problem with location of libraries 64-bit (opensuse)

[M. Edward (Ed) Borasky]

 I've got an openSUSE 11.4 machine using R-patched - do I need to
change anything?

On Thu, May 5, 2011 at 12:55 PM, Detlef Steuer
 wrote:
> Simon,
>
> thank you very much for the detailed answer.
>
>> This shows that rpy2 doesn't setup up the environment correctly (see the R 
>> script for the necessary settings). libR* are NOT supposed to the in 
>> /usr/lib64 - it is a bad hack and very dangerous (programs may pick the 
>> incorrect R libraries). Given that the setup is already messed up it's hard 
>> to tell what causes the gfortran problem.
>
>
> Ok, this mess up is easily identified. In my spec file I link
> $libdir/R/lib/libRblas.so to $libdir/libRblas.so and the same for libR
> and liblapack. Hmm. It works that way for ages, I can`t even vaguely
> remember when and why I introduced that.
> Now I`ve build  R-patched with these links removed.
> At least "here it works". May be that cures rpy2, too.
>
> Thx again
> Detlef
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
http://twitter.com/znmeb http://borasky-research.net

"A mathematician is a device for turning coffee into theorems." -- Paul Erdős

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] problem with location of libraries 64-bit (opensuse)

[Detlef Steuer]

Short answer: No!

I`ll just change/improve the procedure R is built.
Download R-patched tomorrow and some internals a "ordinary" user won`t notice 
will be changed. 

Detlef

On Thu, 5 May 2011 17:09:30 -0700
"M. Edward (Ed) Borasky"  wrote:

>  I've got an openSUSE 11.4 machine using R-patched - do I need to
> change anything?
> 
> On Thu, May 5, 2011 at 12:55 PM, Detlef Steuer
>  wrote:
> > Simon,
> >
> > thank you very much for the detailed answer.
> >
> >> This shows that rpy2 doesn't setup up the environment correctly (see the R 
> >> script for the necessary settings). libR* are NOT supposed to the in 
> >> /usr/lib64 - it is a bad hack and very dangerous (programs may pick the 
> >> incorrect R libraries). Given that the setup is already messed up it's 
> >> hard to tell what causes the gfortran problem.
> >
> >
> > Ok, this mess up is easily identified. In my spec file I link
> > $libdir/R/lib/libRblas.so to $libdir/libRblas.so and the same for libR
> > and liblapack. Hmm. It works that way for ages, I can`t even vaguely
> > remember when and why I introduced that.
> > Now I`ve build  R-patched with these links removed.
> > At least "here it works". May be that cures rpy2, too.
> >
> > Thx again
> > Detlef
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
> 
> 
> -- 
> http://twitter.com/znmeb http://borasky-research.net
> 
> "A mathematician is a device for turning coffee into theorems." -- Paul Erdős


signature.asc
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel