Re: [Rd] gdb
>Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > > On 4 February 2008 at 01:51, Joe Bloggs wrote: > | Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > | > | > On 3 February 2008 at 01:08, Joe Bloggs wrote: > | > | I am using gdb to debug a c++ library I made for R using Rcpp. > | > | However, when I step through the code it seems to go all over the > place, and some of the variables have been optimized out so I can't see their > values. > | > | How can I compile without optimization? > | > > | > Set MAKEFLAGS accordingly, possibly by editing R's Makeconf. This is > | > documented in the 'R Extensions' manual. > | > > | > | Thanks, for the benefit of others.. > | > | I changed the CXXFLAGS line in /etc/R/Makeconf from: > | > | CXXFLAGS = -g -O2 > | > | to: > | > | CXXFLAGS = -ggdb -O2 > > Hm, I never seem to have needed -ggdb, for me -g was usually suffcient. Any > idea why you needed -ggdb ? > > | which seems to work. Changing -O2 to just -O would remove compiler > optimizations, but it turns out this wasn't necessary. Oops, sorry, I must have made a mistake. Tried it again this morning and realize that I do need to remove compiler optimizations. So probably -g will work just as well as -ggdb, but -O is needed instead of -O2. > | Alternatively I could compile my package with > | > | MAKEFLAGS="CXXFLAGS=-ggdb -O2" R CMD INSTALL ... > | > | to temporarily change the flags. > | > | > | > | Also, is there any neat way to run R with gdb through emacs? > | > > | > Yes, using 'M-x gdb' to launcg the gdb frontend. I also use ddd on Linux. > | > > | > Using the debugger is also described in the 'R Extensions' manual. > | > > | > | In the manual it says to run R through gdb by: R -d gdb > | how can I do this in emacs? > | Alternatively how do I run R through gdb after alreay starting gdb? > > I thought that was in the manual, but it seems it isn't. Doug Bates > describes it once or twice a few years back; one quick Google search leads to > > http://tolstoy.newcastle.edu.au/R/help/03a/0566.html > > Hope this helps, Dirk > Thanks for the link, I also found this: http://cran.r-project.org/doc/FAQ/R-FAQ.html#Debugging-R-from-within-Emacs (should have checked earlier!) However, I can't seem to get both R & gdb working together in emacs. I start R in emacs, load the library to be debugged, then start gdb in emacs, attach it to the R process, set the breakpoint, type "signal 0" in gdb to let R take control, then run the R function I am debugging and... emacs hangs up on me :( I can get it to work if I run R in a seperate shell, and run gdb from emacs, attaching it to the R process as before. If I also load the source for the package I'm debugging then it also shows me whereabouts in that file I am which is very nice. > | > | > Hope this helps, Dirk > | > > | > -- > | > Three out of two people have difficulties with fractions. > | > > | > __ > | > 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 > > -- > Three out of two people have difficulties with fractions. > > __ > 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
Re: [Rd] strftime fails on POSIXct objects (PR#10695)
[EMAIL PROTECTED] wrote:
> R 2.6.1 on a Thinkpad T60 running up-to-date Gentoo:
>
> Despite the documentation, which says:
>
> 'strftime' is an alias for 'format.POSIXlt', and 'format.POSIXct'
> first converts to class '"POSIXlt"' by calling 'as.POSIXlt'. Note
> that only that conversion depends on the time zone.
>
> strftime fails on POSIXct objects:
>
>
I think the author of those lines would point out that they do NOT imply
that it shouldn't fail In fact, why would you expect
format.POSIXlt(x) to work on anything but POSIXlt objects?
-p
>> foo <- as.POSIXct(strptime(x='2007-09-22', format='%Y-%m-%d'))
>> strftime(x=foo, format='%Y-%m-%d')
>>
> Error in strftime(x = foo, format = "%Y-%m-%d") : wrong class
>
> It's pretty clear why, given the first two lines of the function:
>
>> strftime
>>
> function (x, format = "", usetz = FALSE, ...)
> {
> if (!inherits(x, "POSIXlt"))
> stop("wrong class")
> if (format == "") {
> times <- unlist(unclass(x)[1:3])
> secs <- x$sec
> secs <- secs[!is.na(secs)]
> np <- getOption("digits.secs")
> if (is.null(np))
> np <- 0
> else np <- min(6, np)
> if (np >= 1) {
> for (i in (1:np) - 1) if (all(abs(secs - round(secs,
> i)) < 1e-06)) {
> np <- i
> break
> }
> }
> format <- if (all(times[!is.na(times)] == 0))
> "%Y-%m-%d"
> else if (np == 0)
> "%Y-%m-%d %H:%M:%S"
> else paste("%Y-%m-%d %H:%M:%OS", np, sep = "")
> }
> .Internal(format.POSIXlt(x, format, usetz))
> }
>
>
>
> /Don Allen
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] strftime fails on POSIXct objects (PR#10695)
R 2.6.1 on a Thinkpad T60 running up-to-date Gentoo:
Despite the documentation, which says:
'strftime' is an alias for 'format.POSIXlt', and 'format.POSIXct'
first converts to class '"POSIXlt"' by calling 'as.POSIXlt'. Note
that only that conversion depends on the time zone.
strftime fails on POSIXct objects:
> foo <- as.POSIXct(strptime(x='2007-09-22', format='%Y-%m-%d'))
> strftime(x=foo, format='%Y-%m-%d')
Error in strftime(x = foo, format = "%Y-%m-%d") : wrong class
It's pretty clear why, given the first two lines of the function:
> strftime
function (x, format = "", usetz = FALSE, ...)
{
if (!inherits(x, "POSIXlt"))
stop("wrong class")
if (format == "") {
times <- unlist(unclass(x)[1:3])
secs <- x$sec
secs <- secs[!is.na(secs)]
np <- getOption("digits.secs")
if (is.null(np))
np <- 0
else np <- min(6, np)
if (np >= 1) {
for (i in (1:np) - 1) if (all(abs(secs - round(secs,
i)) < 1e-06)) {
np <- i
break
}
}
format <- if (all(times[!is.na(times)] == 0))
"%Y-%m-%d"
else if (np == 0)
"%Y-%m-%d %H:%M:%S"
else paste("%Y-%m-%d %H:%M:%OS", np, sep = "")
}
.Internal(format.POSIXlt(x, format, usetz))
}
>
/Don Allen
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in La.svd(x, nu, nv) : error code 1 from Lapack routine 'dgesdd' (PR#10694)
Full_Name: A Ho-Foster Version: R 2.6.1 OS: Win XP Home Submission from: (NULL) (168.167.180.199) Hi I am using a package called Amelia, and it gives this error while it is performing bootstrapping: Error in La.svd(x, nu, nv) : error code 1 from Lapack routine 'dgesdd' I have consulted Amelia archives, and users have commented it is an issue with R, to do with optimising commands. They suggest I can try executing the same commands on an installation of R on another machine. I have tried three different machines, and encounter the same error. I do not have any machines running anything other than Win XP, so I am now looking for another strategy for overcoming this error. Is there anyone familiar with Lapack that might be able to assist? Any assistance would be greatly appreciated. Ari. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] a != a*1 != a+0 != +a
hits=1.0 tests=MANY_EXCLAMATIONS
X-USF-Spam-Flag: NO
Hi
I am writing a package for multivariate polynomials ('multipols')
using S3 methods.
The package includes a Ops.multipol() function for the
arithmetic methods; I would like
to define some sort of user-specified Boolean option which, if
set, would force results to be simplified as they are produced.
Call this option "trim". Trimming a multipol results in
a smaller array that is more manageable.
Mostly one wants to trim, sometimes not.
Would options() be a good way to manage this?
One issue is the behaviour of unary operators "+" and "-".
If trim is TRUE, then "a" is one thing, but "+a" returns
"trim(a)", which might be different.
Also "1*a" would be different from "a" and "a+0"
Does the List consider this to be Good Practice?
Has anyone got comments?
--
Robin Hankin
Uncertainty Analyst and Neutral Theorist,
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strftime fails on POSIXct objects (PR#10695)
On Feb 4, 2008 9:49 AM, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > R 2.6.1 on a Thinkpad T60 running up-to-date Gentoo:
> >
> > Despite the documentation, which says:
> >
> > 'strftime' is an alias for 'format.POSIXlt', and 'format.POSIXct'
> > first converts to class '"POSIXlt"' by calling 'as.POSIXlt'. Note
> > that only that conversion depends on the time zone.
> >
> > strftime fails on POSIXct objects:
> >
> >
> I think the author of those lines would point out that they do NOT imply
> that it shouldn't fail In fact, why would you expect
> format.POSIXlt(x) to work on anything but POSIXlt objects?
Ah, you are quite right -- I mis-read the documentation.
Thanks --
/Don Allen
>
> -p
>
>
> >> foo <- as.POSIXct(strptime(x='2007-09-22', format='%Y-%m-%d'))
> >> strftime(x=foo, format='%Y-%m-%d')
> >>
> > Error in strftime(x = foo, format = "%Y-%m-%d") : wrong class
> >
> > It's pretty clear why, given the first two lines of the function:
> >
> >> strftime
> >>
> > function (x, format = "", usetz = FALSE, ...)
> > {
> > if (!inherits(x, "POSIXlt"))
> > stop("wrong class")
> > if (format == "") {
> > times <- unlist(unclass(x)[1:3])
> > secs <- x$sec
> > secs <- secs[!is.na(secs)]
> > np <- getOption("digits.secs")
> > if (is.null(np))
> > np <- 0
> > else np <- min(6, np)
> > if (np >= 1) {
> > for (i in (1:np) - 1) if (all(abs(secs - round(secs,
> > i)) < 1e-06)) {
> > np <- i
> > break
> > }
> > }
> > format <- if (all(times[!is.na(times)] == 0))
> > "%Y-%m-%d"
> > else if (np == 0)
> > "%Y-%m-%d %H:%M:%S"
> > else paste("%Y-%m-%d %H:%M:%OS", np, sep = "")
> > }
> > .Internal(format.POSIXlt(x, format, usetz))
> > }
> >
> >
> >
> > /Don Allen
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
>O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a != a*1 != a+0 != +a
> One issue is the behaviour of unary operators "+" and "-". > > If trim is TRUE, then "a" is one thing, but "+a" returns > "trim(a)", which might be different. > > Also "1*a" would be different from "a" and "a+0" I think this is ok. In the ggplot2 package I use + to join together multiple plots, where a + b != b + a, and a + b + c (sometimes) = a. This doesn't seem to cause much confusion for users. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#10696) maybe a bug in the system.time() function?
You will get yelled at by others for posting a question as a bug... (sigh). See FAQ. That said, your understanding of the output of system.time() is wrong. The value you are after is simply user+system. %CPU is essentially user+system/elapsed. It is elapsed which is dependent on system load, not the other two (usually). Back into replying more in the usual R-devel sarcastic style... if you don't understand what user/system/elapsed means, you really have no place studying CPU loads... [EMAIL PROTECTED] wrote: > Full_Name: Alessandra Iacobucci > Version: 2.5.1 > OS: Mac OS X 10.4.11 > Submission from: (NULL) (193.48.71.92) > > > Hi, > I am making some intensive simulations for the testing of a Population Monte > Carlo algorithm. This involves also a study of the CPU times in two different > case. > What I am trying to measure is the "real" CPU time, the one which is > independent > on the %CPU. > > I'm using the "system.time" function with gcFirst=TRUE and I realized that all > of the output values (user, system and elapsed) depend on the percentage of > the > CPU, meaning that if your program is the only one running on the machine, > system.time() gives you certain values, and if there are many programs > running > at the same time, for the exact same simulation system.time() gives you much > higher values. > > Thanks for you answer. > > Best regards, > > Alessandra Iacobucci > > __ > 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] r-release Windows x86_64
I was just looking at the daily checks and it seems the "r-release
Windows x86_64 (32-bit)" column is running R2.6.0. Is that correct?
Possibly related, an error is being flagged in that column for
TSMySQL, which appears to be a problem that should be caught in the
other columns too. It is something that has been fixed in my sources
for awhile. (I think it was fixed in the version on CRAN too, but I'm
not certain.)
Paul Gilbert
La version française suit le texte anglais.
This email may contain privileged and/or confidential in...{{dropped:26}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gdb
> "DE" == Dirk Eddelbuettel <[EMAIL PROTECTED]> > on Sun, 3 Feb 2008 20:22:30 -0600 writes: DE> On 4 February 2008 at 01:51, Joe Bloggs wrote: DE> | Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: DE> | DE> | > On 3 February 2008 at 01:08, Joe Bloggs wrote: DE> | > | I am using gdb to debug a c++ library I made for R using Rcpp. DE> | > | However, when I step through the code it seems to go all over the place, and some of the variables have been optimized out so I can't see their values. DE> | > | How can I compile without optimization? DE> | > DE> | > Set MAKEFLAGS accordingly, possibly by editing R's Makeconf. This is DE> | > documented in the 'R Extensions' manual. DE> | > DE> | DE> | Thanks, for the benefit of others.. DE> | DE> | I changed the CXXFLAGS line in /etc/R/Makeconf from: DE> | DE> | CXXFLAGS = -g -O2 DE> | DE> | to: DE> | DE> | CXXFLAGS = -ggdb -O2 DE> Hm, I never seem to have needed -ggdb, for me -g was usually suffcient. Any DE> idea why you needed -ggdb ? DE> | which seems to work. Changing -O2 to just -O would remove compiler optimizations, but it turns out this wasn't necessary. DE> | Alternatively I could compile my package with DE> | DE> | MAKEFLAGS="CXXFLAGS=-ggdb -O2" R CMD INSTALL ... DE> | DE> | to temporarily change the flags. DE> | DE> | DE> | > | Also, is there any neat way to run R with gdb through emacs? DE> | > DE> | > Yes, using 'M-x gdb' to launcg the gdb frontend. I also use ddd on Linux. DE> | > DE> | > Using the debugger is also described in the 'R Extensions' manual. DE> | > DE> | DE> | In the manual it says to run R through gdb by: R -d gdb DE> | how can I do this in emacs? C-u M-x R [Enter] -d gdb [Enter] === C-u: == Emacs "Prefix" allows you to specify command line arguments to R DE> | Alternatively how do I run R through gdb after alreay starting gdb? DE> I thought that was in the manual, but it seems it isn't. Doug Bates DE> describes it once or twice a few years back; one quick Google search leads to DE> http://tolstoy.newcastle.edu.au/R/help/03a/0566.html DE> Hope this helps, Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-release Windows x86_64
Paul Gilbert wrote:
> I was just looking at the daily checks and it seems the "r-release
> Windows x86_64 (32-bit)" column is running R2.6.0. Is that correct?
Paul,
well, currently it is not checking daily, but new checks are done in
R-2.6.2 RC.
I'll rerun all check today and tomorrow and we will have R-2.6.2 results
on Thursday.
> Possibly related, an error is being flagged in that column for
> TSMySQL, which appears to be a problem that should be caught in the
> other columns too. It is something that has been fixed in my sources
> for awhile. (I think it was fixed in the version on CRAN too, but I'm
> not certain.)
I'll rerun that check at once and you will see if you get a message
reporting the error again.
Best wishes,
Uwe
>
> Paul Gilbert
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential in...{{dropped:26}}
>
> __
> 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
Re: [Rd] a != a*1 != a+0 != +a
I don't think global options are desirable.
I would make your operators work in a single way and if the user
wants a different way he can call whatever functions you provide
directly instead of using the operators.
If you really need two ways with operators I would define a subclass
with operators working in the alternative way and have as.whatever
methods that converts back and forth.
Another possibility is to have the way it works be a special
attribute of the object itself (other than "class").
On Feb 4, 2008 9:25 AM, Robin Hankin <[EMAIL PROTECTED]> wrote:
> hits=1.0 tests=MANY_EXCLAMATIONS
> X-USF-Spam-Flag: NO
>
> Hi
>
> I am writing a package for multivariate polynomials ('multipols')
> using S3 methods.
>
> The package includes a Ops.multipol() function for the
> arithmetic methods; I would like
> to define some sort of user-specified Boolean option which, if
> set, would force results to be simplified as they are produced.
>
> Call this option "trim". Trimming a multipol results in
> a smaller array that is more manageable.
>
> Mostly one wants to trim, sometimes not.
>
>
> Would options() be a good way to manage this?
>
> One issue is the behaviour of unary operators "+" and "-".
>
> If trim is TRUE, then "a" is one thing, but "+a" returns
> "trim(a)", which might be different.
>
> Also "1*a" would be different from "a" and "a+0"
>
>
>
> Does the List consider this to be Good Practice?
>
> Has anyone got comments?
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst and Neutral Theorist,
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
> tel 023-8059-7743
>
> __
> 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] maybe a bug in the system.time() function? (PR#10696)
Full_Name: Alessandra Iacobucci Version: 2.5.1 OS: Mac OS X 10.4.11 Submission from: (NULL) (193.48.71.92) Hi, I am making some intensive simulations for the testing of a Population Monte Carlo algorithm. This involves also a study of the CPU times in two different case. What I am trying to measure is the "real" CPU time, the one which is independent on the %CPU. I'm using the "system.time" function with gcFirst=TRUE and I realized that all of the output values (user, system and elapsed) depend on the percentage of the CPU, meaning that if your program is the only one running on the machine, system.time() gives you certain values, and if there are many programs running at the same time, for the exact same simulation system.time() gives you much higher values. Thanks for you answer. Best regards, Alessandra Iacobucci __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R valgrind question
Daniel Oberski wrote on 02/04/2008 02:21 PM: > Dear R developers > > > I am running an instrumented build of R 2.6.1 on ubuntu, compiled with > option configure --with-valgrind-instrumentation=3. > > If run valgrind R then I get all sorts of warnings. I was wondering > whether I should worry about them or not. Don't worry about them. Those are benign issues with the system libraries.. insofar as you trust those libraries, which you should... in general. Jeff > > First, when I open R as follows: > > $R -d "valgrind --tool=memcheck --leak-check=full > --show-reachable=yes" --vanilla > > I get a whole bunch of > > > ==888== Invalid read of size 4 > ==888==at 0x4014787: (within /lib/ld-2.5.so) > ... > ==888== Address 0x50794A4 is 44 bytes inside a block of size 47 alloc'd > ==888==at 0x4021620: malloc (vg_replace_malloc.c:149) > ==888==by 0x4006EB4: (within /lib/ld-2.5.so) > ... > > Second, when I exit R I get memory leak reports: > > ==888== LEAK SUMMARY: > ==888==definitely lost: 132 bytes in 17 blocks. > ==888==indirectly lost: 240 bytes in 20 blocks. > ==888== possibly lost: 0 bytes in 0 blocks. > ==888==still reachable: 13,110,032 bytes in 6,340 blocks. > ==888== suppressed: 0 bytes in 0 blocks. > > > I am sorry if this is a stupid question, please be gentle. What should > I make of this? > > I was trying to check my own C program (as a standalone program it > does not produce any valgrind warnings), but now I am not sure what is > going on when using valgrind on R.. > > > Best regards, > daniel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- http://biostat.mc.vanderbilt.edu/JeffreyHorner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R valgrind question
Sorry I forgot to mention this happens just starting and then stopping R. I am not running any other commands or loading any packages. > I was trying to check my own C program (as a standalone program it > does not produce any valgrind warnings), but now I am not sure what is > going on when using valgrind on R.. > > > Best regards, > daniel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R valgrind question
Dear R developers I am running an instrumented build of R 2.6.1 on ubuntu, compiled with option configure --with-valgrind-instrumentation=3. If run valgrind R then I get all sorts of warnings. I was wondering whether I should worry about them or not. First, when I open R as follows: $R -d "valgrind --tool=memcheck --leak-check=full --show-reachable=yes" --vanilla I get a whole bunch of ==888== Invalid read of size 4 ==888==at 0x4014787: (within /lib/ld-2.5.so) ... ==888== Address 0x50794A4 is 44 bytes inside a block of size 47 alloc'd ==888==at 0x4021620: malloc (vg_replace_malloc.c:149) ==888==by 0x4006EB4: (within /lib/ld-2.5.so) ... Second, when I exit R I get memory leak reports: ==888== LEAK SUMMARY: ==888==definitely lost: 132 bytes in 17 blocks. ==888==indirectly lost: 240 bytes in 20 blocks. ==888== possibly lost: 0 bytes in 0 blocks. ==888==still reachable: 13,110,032 bytes in 6,340 blocks. ==888== suppressed: 0 bytes in 0 blocks. I am sorry if this is a stupid question, please be gentle. What should I make of this? I was trying to check my own C program (as a standalone program it does not produce any valgrind warnings), but now I am not sure what is going on when using valgrind on R.. Best regards, daniel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building R with Intel MKL v10 BLAS
Michael Braun MIT.EDU> writes:
>
> NO
>
> Hi. I'm not sure if this is an R-help or R-devel problem, so I'm
> starting here in the hope that someone can help (and willing to go to
> the other list if it's more appropriate). I think I am following all of
> the instructions in the various manuals, but clearly I am missing something.
>
> I have an Intel EM64T Dell with 2 dual-core Xeon processors running Red
> Hat EL5. I would like to build R 2.6.1 with lots of debugging and
> profiling options, and link it to the processor-specific Intel MKL blas.
> The problem is that after I compile R, and do R CMD config BLAS_LIBS,
> the response is
> -L/usr/local/lib64/R/lib -lRblas.
>
> This tells me that R is not linked to the Intel BLAS at all.
>
> My config.site file for R is:
>
> #! /bin/sh
>
> R_PAPERSIZE=letter
> CFLAGS="-g -O2 -p -pg"
> CPPFLAGS="-I/opt/intel/mkl/10.0.1.014/include -I/usr/include
> -I/usr/local/include"
> LIBnn=lib64
> BLAS_LIBS="-L/opt/intel/mkl/10.0.1.014/lib/em64t -Wl,--start-group
> -lmkl_gf_lp64.so -lmkl_gnu_thread.so -lmkl_core.so -l -l -l -Wl,
> --end-group -lguide -lpthread -lm"
>
> I have set the CONFIG_SITE environment variable to the location of the
> config.site.file.
> I am doing everything as superuser.
>
> The command I am using for configure is
>
> ./configure --disable-R-profiling --with-blas=no
>
> following the instructions in the R-admin file regarding enabling
> C-level profiling and linking to the external BLAS libraries referenced
> in the config.site file.
>
> The BLAS_LIBS files are different than in the R-admin manual because of
> changes in the Intel MKL for version 10. These libraries, in this
> order, were taken from the Intel MKL for Linux User's Guide, chapter 5.
>
> So, still no luck linking to the optimized BLAS. I'd appreciate any
> suggestions.
>
> Thanks,
>
> Michael
>
---
I now recall a similar problem with my install of MKL V10. Here is the info:
I got the 10.X, layered library version of MKL 10.X working on R-2.6.1a. I
set the full path information for the R configuration blas and lapack
option:
--with-blas="-L/.../intel/mkl/10.0.011/lib/em64t -lRblas -lmkl_sequential
-lmkl_lapack -lmkl_core -lpthread"
--with-lapack="-L/.../intel/mkl/10.0.011/lib/em64t -lRlapack -lmkl_sequential
-lmkl_lapack -lmkl_core -lpthread"
In this case, libRblas.so and libRlapack.so are both linked to
libmkl_gf_lp64.so in the em64t directory. There must be some internal error
in the R configuration and make processing, because it would not pick up the
primary path specification for the mkl libraries location. Instead, I was
able to define:
***critical step to get around a possible R bug***
sh-3.00$ export LD_RUN_PATH=/.../intel/mkl/10.0.011/lib/em64t
After that, I was able to perform the R configure with no errors. Then the
make also worked with no errors. The BLAS_LIBS and LAPACK_LIBS variables
were properly defined, and the path to the MKL libraries was properly
defined in ldpaths:
sh-3.00$ /.../R-2.6.1a/bin/R CMD config BLAS_LIBS
-L/.../intel/mkl/10.0.011/lib/em64t -lRblas -lmkl_sequential -lmkl_lapack
-lmkl_core -lpthread
sh-3.00$ /.../R-2.6.1a/bin/R CMD config LAPACK_LIBS
-L/.../R-2.6.1a/intel/mkl/10.0.011/lib/em64t -lRlapack -lmkl_sequential
-lmkl_lapack -lmkl_core -lpthread
sh-3.00$
power02(43)% more ldpaths
...
${R_LD_LIBRARY_PATH=${R_HOME}/lib:/s/gcc-4.2.1/lib64:
/.../intel/mkl/10.0.011/lib/em64t:/usr/X11R6/lib64:
/.../tcl-8.4.2/i386_rh72/lib:/.../XFree86-4.2.1/i386_rh72/lib}
(... are the various local paths to the objects of interest)
Hope that helps (maybe more than my other post)
MJR
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building R with Intel MKL v10 BLAS
Ei-ji Nakama ki.rim.or.jp> writes:
>
> Hi.
>
> 2008/1/25, Michael Braun mit.edu>:
> > NO
> >
> > Hi. I'm not sure if this is an R-help or R-devel problem, so I'm
> > starting here in the hope that someone can help (and willing to go to
> > the other list if it's more appropriate). I think I am following all of
> > the instructions in the various manuals, but clearly I am missing something.
> >
> > I have an Intel EM64T Dell with 2 dual-core Xeon processors running Red
> > Hat EL5. I would like to build R 2.6.1 with lots of debugging and
> > profiling options, and link it to the processor-specific Intel MKL blas.
> > The problem is that after I compile R, and do R CMD config BLAS_LIBS,
> > the response is
> > -L/usr/local/lib64/R/lib -lRblas.
> >
> > This tells me that R is not linked to the Intel BLAS at all.
> >
> > My config.site file for R is:
> >
> > #! /bin/sh
> >
> > R_PAPERSIZE=letter
> > CFLAGS="-g -O2 -p -pg"
> > CPPFLAGS="-I/opt/intel/mkl/10.0.1.014/include -I/usr/include
> > -I/usr/local/include"
> > LIBnn=lib64
> > BLAS_LIBS="-L/opt/intel/mkl/10.0.1.014/lib/em64t -Wl,--start-group
> > -lmkl_gf_lp64.so -lmkl_gnu_thread.so -lmkl_core.so -l -l -l -Wl,
> > --end-group -lguide -lpthread -lm"
>
> I have an AMD 64x2 Debian(etch)
> $ gcc-4.2 -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../gcc-4.2.2/configure -v
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang
> --prefix=/usr/local/gcc-4.2.2 --enable-shared --disable-multilib
> --with-system-zlib --without-included-gettext --enable-threads=posix
> --enable-nls --program-suffix=-4.2 --enable-__cxa_atexit
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
> --enable-checking=release x86_64-linux-gnu
> Thread model: posix
> gcc version 4.2.2
>
> MKL_LIB_PATH=/opt/intel/mkl/10.0.1.014/lib/em64t
> MKL=" -L${MKL_LIB_PATH} \
> -Wl,--start-group \
> ${MKL_LIB_PATH}/libmkl_gf_lp64.a\
> ${MKL_LIB_PATH}/libmkl_gnu_thread.a \
> ${MKL_LIB_PATH}/libmkl_core.a \
> -Wl,--end-group \
> -liomp5 -lguide -lpthread -lgomp"
>
> ./configure CC=gcc-4.2\
> CXX=g++-4.2\
> F77=gfortran-4.2\
> FC=gfortran-4.2\
> --with-lapack="$MKL" --with-blas="$MKL"
>
> mkl_core seemed to want to cause libiomp5. dgemm gave a funny result
> in matrix of 1000x1000 if I did not link with real libiomp5.
>
---
According to Intel, the V10 MKL is modular and therefore requires that all the
needed modules be on the library path in the correct order. This differs from V9
in that the single BLAS and LAPACK libraries could be directly substituted
(linked from) libRblas.so and libRlapack.so. To build, I needed to add the paths
into the config.sh and make sure all the tests worked during R build. These are
the config.sh entries. I think the result is similar to what is noted above,
though I use the intel thread rather than the gnu thread. I tried both, and
don't recall that it made a difference:
--with-blas="-L/.../intel/mkl/10.0.1.014/lib/em64t -lRblas -lmkl_intel_thread
-lguide -lmkl_lapack -lmkl_core -lpthread" \
--with-lapack="-L/.../intel/mkl/10.0.1.014/lib/em64t -lRlapack
-lmkl_intel_thread -lguide -lmkl_lapack -lmkl_core -lpthread" \
where ... is the absolute path to your Intel MKL installation.
Hope that helps...
MJR
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
