Re: [Rd] R CMD check ignores .Rbuildignore?
> "RossB" == Ross Boylan <[EMAIL PROTECTED]> > on Sun, 18 Mar 2007 12:39:14 -0700 writes: RossB> The contents of .Rbuildignore seems to affect RossB> R CMD build RossB> but not RossB> R CMD check. RossB> I'm using R 2.4.0 on Debian. RossB> Is my understanding correct? yes. That's why it's called 'buildignore'. It's a big feature for me as package developer: E.g., I can have extra tests (which e.g. only apply on my specific platform) in addition to those which are use when the package is built (to be checked on all possible platforms). Some have proposed to additionally define a '.Rcheckignore' but they haven't been convincing enough. RossB> And is there anything I can do about it? "First build, then check" is one way; Something which is recommended anyway in some cases, e.g., if you have an (Sweave - based) vignette. RossB> In my case, some of the excluded files contain references to other RossB> libraries, so linking fails under R CMD check. I realize I could add RossB> the library to the build (with Makevars, I guess), but I do not want RossB> to introduce the dependency. It depends on the circumstances on how I would solve this problem [Why have these files as part of the package sources at all?] Regads, Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eigen returns NAs from a real matrix
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Sun, 18 Mar 2007 06:51:58 + (GMT) writes:
BDR> On Sat, 17 Mar 2007, Spencer Graves wrote:
>> Hi, All:
>> Attached please find a symmetric, indefinite matrix for which
>> 'eigen(...)$vectors' included NAs:
>>> load("eigenBug.Rdata")
>>> sum(is.na(eigen(eigenBug)$vectors))
>> [1] 5670
>>> sessioninfo()
>> Error: could not find function "sessioninfo"
>>> sessionInfo()
>> R version 2.4.1 (2006-12-18)
>> i386-pc-mingw32
>>
>> locale:
>> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>>
>> attached base packages:
>> [1] "stats" "graphics" "grDevices" "utils" "datasets"
"methods" [7]
>> "base"
>> Using EISPACK does NOT return NAs: > sum(is.na(eigen(eigenBug,
>> EISPACK=TRUE)$vectors))
>> [1] 0
>>
>>
>> I traced the problem to the following line in 'eigen':
>> z <- if (!complex.x)
>> .Call("La_rs", x, only.values, PACKAGE = "base")
>>
>>
>> Comments?
BDR> Nothing appeared as an attachment.
it was a zip file which is not among the allowed ones
(.tar.gz / *.tgz would work).
Spencer has also contacted me in private,
so you now can use something like :
F <- tempfile()
download.file("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";, F)
load(F)
str(eigenBug)# tons of dinames; get rid of them:
M <- unname(eigenBug)
sum(is.na(eigen(M)$vectors))
# 0 (for MM, on Linux); '5670' for Spencer
sum(is.na(eigen(M, EISPACK=TRUE)$vectors))
# 0
## Guess about what kind of BLAS/Lapack I'm using :
file.info(list.files(R.home("lib"), full=TRUE))[,1:3]
##size isdir mode
## 64-linux-inst/lib/libRblas.so422558 FALSE 755
## 64-linux-inst/lib/libRlapack.so 3144596 FALSE 755
I.e. I don't get any NA's
which shows to me that the bug is most probably in the Lapack -
Version that Spencer's version of R is linked against.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R4.1: seq.POSIXt, tz="AEST" (PR#9572)
Times from seq.POSIXt come out wrong in AEST timezone around Feb 29 every
leap year before 1970 (on Windows XP).
According to help(DateTimeClasses), this is handled by "our own C code".
> x <- as.POSIXct("1968-02-27") # tz="AEST"
> x.gmt <- as.POSIXct("1968-02-27", tz="GMT")
> data.frame(
GMT=seq(x.gmt, by="day", length=8),
byday=seq(x, by="day", length=8),
byDST=seq(x, by="DSTday", length=8))
GMT byday byDST
1 1968-02-27 1968-02-27 1968-02-27
2 1968-02-28 1968-02-28 1968-02-28
3 1968-02-29 1968-03-01 1968-03-02
4 1968-03-01 1968-03-02 1968-03-02
5 1968-03-02 1968-03-02 1968-03-02
6 1968-03-03 1968-03-03 1968-03-03
7 1968-03-04 1968-03-04 1968-03-04
8 1968-03-05 1968-03-05 1968-03-05
> R.version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 4.1
year 2006
month 12
day18
svn rev40228
language R
version.string R version 2.4.1 (2006-12-18)
--
Felix Andrews / $B0BJ!N)(B
Beijing Bag, Locked Bag 40, Kingston ACT 2604
Building 48A, Linnaeus Way, The Australian National University ACT 0200
Australia
http://www.neurofractal.org/felix/
mailto:[EMAIL PROTECTED]
voice:+86_1051404394 (in China)
mobile:+86_13522529265 (in China)
mobile:+61_410400963 (in Australia)
xmpp:[EMAIL PROTECTED]
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R4.1: seq.POSIXt, tz="AEST" (PR#9572)
Hmm, AEST is not a valid time zone on Windows.
See ?as.POSIXlt for one of several places where this is documented.
But in any case, the underlying problem is in the OS, and we only try to
work around it to the best of our knowledge (and that excludes
undocumented time zones).
On Mon, 19 Mar 2007, [EMAIL PROTECTED] wrote:
> Times from seq.POSIXt come out wrong in AEST timezone around Feb 29 every
> leap year before 1970 (on Windows XP).
>
> According to help(DateTimeClasses), this is handled by "our own C code".
>
>> x <- as.POSIXct("1968-02-27") # tz="AEST"
>> x.gmt <- as.POSIXct("1968-02-27", tz="GMT")
>> data.frame(
> GMT=seq(x.gmt, by="day", length=8),
> byday=seq(x, by="day", length=8),
> byDST=seq(x, by="DSTday", length=8))
> GMT byday byDST
> 1 1968-02-27 1968-02-27 1968-02-27
> 2 1968-02-28 1968-02-28 1968-02-28
> 3 1968-02-29 1968-03-01 1968-03-02
> 4 1968-03-01 1968-03-02 1968-03-02
> 5 1968-03-02 1968-03-02 1968-03-02
> 6 1968-03-03 1968-03-03 1968-03-03
> 7 1968-03-04 1968-03-04 1968-03-04
> 8 1968-03-05 1968-03-05 1968-03-05
>
>> R.version
> _
> platform i386-pc-mingw32
> arch i386
> os mingw32
> system i386, mingw32
> status
> major 2
> minor 4.1
> year 2006
> month 12
> day18
> svn rev40228
> language R
> version.string R version 2.4.1 (2006-12-18)
>
>
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.5.0 slated for April 24
This is to announce that we plan to release R version 2.5.0 on Tuesday April 24, 2007. The following information is mainly for developers, package maintainers and repository maintainers. The planned procedure is March 27: "Grand Feature" Freeze 2.5.0 alpha April 10: Feature Freeze 2.5.0 beta April 17: Code Freeze 2.5.0 RC April 24: Release 2.5.0 GFF: No major restructuring past this point FF: Feature set complete, only bugfixing from now on CF: Only critical bugfixes and platform build issues Maintainers of recommended packages should notice that as they become part of the final R tarball, we expect them to follow a similar freeze pattern (and beware of potential CRAN delays, so please do not cut it too close to the deadlines). Notice that the main structural discontinuities occurs at GFF: The SVN repository is affected as follows The trunk version is set to "2.6.0 Under development (unstable)". A new branch, R-2-5-branch is created. This also implies new version numbers for "r-devel" and "r-release-branch", in the sense of http://developer.r-project.org/SVNtips.html Also, "r-release-branch" needs to have its tag updated. Repository maintainers may need to revise directory structures accordingly. "R 2.4.1 Patched" will be closed to further development at GFF (as all the release branches, it can be reopened if the need arises, we just don't anticipate such a need.) The source alpha/beta/RC tarballs will be made available daily (barring build troubles) by a cron job running at 5AM CET, and the tarballs can be picked up at http://cran.r-project.org/src/base-prerelease/ a little later. The various freeze points are marked by changes to the VERSION file this is also done automatically by a cron job which runs just after midnight on the relevant days. -- 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] R CMD CHECK problem
I tried two times to get some help for this from the help list but to no avail.
I hope,
it's OK to post this here (once...). if not, please ignore (the rest of) this
mail:
for one of my private packages R CMD CHECK {package} givves me annoying warnings
due to 'missing links' in the manpages for functions from another private
package mentioned in the manpages. specifically, I have two packages, the first
(named `pkc') depending on the second one (named `roiutils'). The source code
and DESCRIPTION files describes the dependency as it should be, I think
('Imports', `require'). but if I run
R CMD CHECK pkc
I get "significant warnings" related to missing links (refering to functions
from the second package) in the manpages of the first package as can be
seen below. despite the warnings, after installing the two packages the help
system works just fine including the cross-references.
my question:
why is it, that R CMD CHECK is complaining? what am I doing wrong?
how have I to specify the links in the manpages to tell CHECK that
everything is basically OK?
CUT
* checking for working latex ... OK
* using log directory '/Users/vdh/rfiles/Rlibrary/.check/pkc.Rcheck'
* using R version 2.4.0 (2006-10-03)
* checking for file 'pkc/DESCRIPTION' ... OK
* this is package 'pkc' version '1.1'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'pkc' can be installed ... WARNING
Found the following significant warnings:
missing link(s): readroi readroi readroi figure readroi conv3exmodel
readroi
missing link(s): figure readroi
* checking package directory ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for syntax errors ... OK
* checking R files for non-ASCII characters ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the name space can be loaded with stated dependencies ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... WARNING
Rd files with unknown sections:
/Users/vdh/rfiles/Rlibrary/pkc/man/fitdemo.Rd: example
See the chapter 'Writing R documentation files' in manual 'Writing R
Extensions'.
* checking Rd cross-references ... WARNING
Missing link(s) in documentation object 'compfit.Rd':
readroi readroi readroi figure readroi conv3exmodel readroi
Missing link(s) in documentation object 'exp3fit.Rd':
figure readroi
CUT
any hints appreciated,
joerg
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eigen returns NAs from a real matrix
On 3/19/2007 6:48 AM, Martin Maechler wrote:
>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>> on Sun, 18 Mar 2007 06:51:58 + (GMT) writes:
>
> BDR> On Sat, 17 Mar 2007, Spencer Graves wrote:
> >> Hi, All:
> >> Attached please find a symmetric, indefinite matrix for which
> >> 'eigen(...)$vectors' included NAs:
> >>> load("eigenBug.Rdata")
> >>> sum(is.na(eigen(eigenBug)$vectors))
> >> [1] 5670
> >>> sessioninfo()
> >> Error: could not find function "sessioninfo"
> >>> sessionInfo()
> >> R version 2.4.1 (2006-12-18)
> >> i386-pc-mingw32
> >>
> >> locale:
> >> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> >> States.1252;LC_MONETARY=English_United
> >> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
> >>
> >> attached base packages:
> >> [1] "stats" "graphics" "grDevices" "utils" "datasets"
> "methods" [7]
> >> "base"
> >> Using EISPACK does NOT return NAs: > sum(is.na(eigen(eigenBug,
> >> EISPACK=TRUE)$vectors))
> >> [1] 0
> >>
> >>
> >> I traced the problem to the following line in 'eigen':
> >> z <- if (!complex.x)
> >> .Call("La_rs", x, only.values, PACKAGE = "base")
> >>
> >>
> >> Comments?
>
> BDR> Nothing appeared as an attachment.
>
> it was a zip file which is not among the allowed ones
> (.tar.gz / *.tgz would work).
>
> Spencer has also contacted me in private,
> so you now can use something like :
>
> F <- tempfile()
> download.file("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";, F)
> load(F)
This is unrelated to Spencer's problem, but this sequence failed for me.
By default it will treat the file as a text file, and convert EOL
markers for Windows. Adding "mode='wb'" to the download.file() call is
necessary.
> str(eigenBug)# tons of dinames; get rid of them:
> M <- unname(eigenBug)
>
> sum(is.na(eigen(M)$vectors))
> # 0 (for MM, on Linux); '5670' for Spencer
I get the same as Spencer in 2.4.1, but zero in R-devel, in Windows. I
haven't tried R-patched yet: there were network problems here this
morning, and the build failed.
Duncan Murdoch
> sum(is.na(eigen(M, EISPACK=TRUE)$vectors))
> # 0
>
> ## Guess about what kind of BLAS/Lapack I'm using :
> file.info(list.files(R.home("lib"), full=TRUE))[,1:3]
> ##size isdir mode
> ## 64-linux-inst/lib/libRblas.so422558 FALSE 755
> ## 64-linux-inst/lib/libRlapack.so 3144596 FALSE 755
>
>
> I.e. I don't get any NA's
> which shows to me that the bug is most probably in the Lapack -
> Version that Spencer's version of R is linked against.
>
> Martin Maechler, ETH Zurich
>
> __
> 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] eigen returns NAs from a real matrix
> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
> on Mon, 19 Mar 2007 09:01:39 -0400 writes:
Duncan> On 3/19/2007 6:48 AM, Martin Maechler wrote:
>>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>>> on Sun, 18 Mar 2007 06:51:58 + (GMT) writes:
>>
BDR> On Sat, 17 Mar 2007, Spencer Graves wrote:
>> >> Hi, All:
>> >> Attached please find a symmetric, indefinite matrix for which
>> >> 'eigen(...)$vectors' included NAs:
>> >>> load("eigenBug.Rdata")
>> >>> sum(is.na(eigen(eigenBug)$vectors))
>> >> [1] 5670
>> >>> sessioninfo()
>> >> Error: could not find function "sessioninfo"
>> >>> sessionInfo()
>> >> R version 2.4.1 (2006-12-18)
>> >> i386-pc-mingw32
>> >>
>> >> locale:
>> >> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> >> States.1252;LC_MONETARY=English_United
>> >> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>> >>
>> >> attached base packages:
>> >> [1] "stats" "graphics" "grDevices" "utils" "datasets"
"methods" [7]
>> >> "base"
>> >> Using EISPACK does NOT return NAs: > sum(is.na(eigen(eigenBug,
>> >> EISPACK=TRUE)$vectors))
>> >> [1] 0
>> >>
>> >>
>> >> I traced the problem to the following line in 'eigen':
>> >> z <- if (!complex.x)
>> >> .Call("La_rs", x, only.values, PACKAGE = "base")
>> >>
>> >>
>> >> Comments?
>>
BDR> Nothing appeared as an attachment.
>>
>> it was a zip file which is not among the allowed ones
>> (.tar.gz / *.tgz would work).
>>
>> Spencer has also contacted me in private,
>> so you now can use something like :
>>
>> F <- tempfile()
>> download.file("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";, F)
>> load(F)
Duncan> This is unrelated to Spencer's problem, but this
Duncan> sequence failed for me.
Duncan> By default it will treat the file as a text file,
Duncan> and convert EOL markers for Windows. Adding
Duncan> "mode='wb'" to the download.file() call is necessary.
ok; Thank you, Duncan.
{For me, that's yet another reason why I think it would be ``nice''
if both load() and source() would work with general
connections the same way as read.table(), and I could just say
load("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";)
}
>> str(eigenBug)# tons of dinames; get rid of them:
>> M <- unname(eigenBug)
>>
>> sum(is.na(eigen(M)$vectors))
>> # 0 (for MM, on Linux); '5670' for Spencer
Duncan> I get the same as Spencer in 2.4.1, but zero in
Duncan> R-devel, in Windows.
ahh, that's good news.
Maybe Spencer could install a revcent version R-devel on his
Windows machine, and try the example?
Duncan> I haven't tried R-patched yet: there were network
Duncan> problems here this morning, and the build failed.
Duncan> Duncan Murdoch
>> sum(is.na(eigen(M, EISPACK=TRUE)$vectors))
>> # 0
>>
>> ## Guess about what kind of BLAS/Lapack I'm using :
>> file.info(list.files(R.home("lib"), full=TRUE))[,1:3]
>> ##size isdir mode
>> ## 64-linux-inst/lib/libRblas.so422558 FALSE 755
>> ## 64-linux-inst/lib/libRlapack.so 3144596 FALSE 755
>>
>>
>> I.e. I don't get any NA's
>> which shows to me that the bug is most probably in the Lapack -
>> Version that Spencer's version of R is linked against.
>>
>> Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD CHECK problem
Joerg van den Hoff wrote:
> I tried two times to get some help for this from the help list but to no
> avail. I hope,
> it's OK to post this here (once...). if not, please ignore (the rest of) this
> mail:
>
> for one of my private packages R CMD CHECK {package} givves me annoying
> warnings
> due to 'missing links' in the manpages for functions from another private
> package mentioned in the manpages. specifically, I have two packages, the
> first
> (named `pkc') depending on the second one (named `roiutils'). The source code
> and DESCRIPTION files describes the dependency as it should be, I think
> ('Imports', `require'). but if I run
>
> R CMD CHECK pkc
>
> I get "significant warnings" related to missing links (refering to functions
> from the second package) in the manpages of the first package as can be
> seen below. despite the warnings, after installing the two packages the help
> system works just fine including the cross-references.
>
> my question:
> why is it, that R CMD CHECK is complaining? what am I doing wrong?
> how have I to specify the links in the manpages to tell CHECK that
> everything is basically OK?
Specify links in the form \link[roiutils]{readroi} as the Writing R
Extension manual suggests.
Uwe Ligges
> CUT
> * checking for working latex ... OK
> * using log directory '/Users/vdh/rfiles/Rlibrary/.check/pkc.Rcheck'
> * using R version 2.4.0 (2006-10-03)
> * checking for file 'pkc/DESCRIPTION' ... OK
> * this is package 'pkc' version '1.1'
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking whether package 'pkc' can be installed ... WARNING
> Found the following significant warnings:
>missing link(s): readroi readroi readroi figure readroi conv3exmodel
> readroi
>missing link(s): figure readroi
> * checking package directory ... OK
> * checking for portable file names ... OK
> * checking for sufficient/correct file permissions ... OK
> * checking DESCRIPTION meta-information ... OK
> * checking top-level files ... OK
> * checking index information ... OK
> * checking package subdirectories ... OK
> * checking R files for syntax errors ... OK
> * checking R files for non-ASCII characters ... OK
> * checking whether the package can be loaded ... OK
> * checking whether the package can be loaded with stated dependencies ... OK
> * checking whether the name space can be loaded with stated dependencies ...
> OK
> * checking S3 generic/method consistency ... OK
> * checking replacement functions ... OK
> * checking foreign function calls ... OK
> * checking R code for possible problems ... OK
> * checking Rd files ... WARNING
> Rd files with unknown sections:
> /Users/vdh/rfiles/Rlibrary/pkc/man/fitdemo.Rd: example
>
> See the chapter 'Writing R documentation files' in manual 'Writing R
> Extensions'.
> * checking Rd cross-references ... WARNING
> Missing link(s) in documentation object 'compfit.Rd':
> readroi readroi readroi figure readroi conv3exmodel readroi
>
> Missing link(s) in documentation object 'exp3fit.Rd':
> figure readroi
> CUT
>
>
> any hints appreciated,
>
> joerg
>
> __
> 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] eigen returns NAs from a real matrix
On 3/19/2007 9:12 AM, Martin Maechler wrote:
>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>> on Mon, 19 Mar 2007 09:01:39 -0400 writes:
>
> Duncan> On 3/19/2007 6:48 AM, Martin Maechler wrote:
> >>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> >>> on Sun, 18 Mar 2007 06:51:58 + (GMT) writes:
> >>
> BDR> On Sat, 17 Mar 2007, Spencer Graves wrote:
> >> >> Hi, All:
> >> >> Attached please find a symmetric, indefinite matrix for which
> >> >> 'eigen(...)$vectors' included NAs:
> >> >>> load("eigenBug.Rdata")
> >> >>> sum(is.na(eigen(eigenBug)$vectors))
> >> >> [1] 5670
> >> >>> sessioninfo()
> >> >> Error: could not find function "sessioninfo"
> >> >>> sessionInfo()
> >> >> R version 2.4.1 (2006-12-18)
> >> >> i386-pc-mingw32
> >> >>
> >> >> locale:
> >> >> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> >> >> States.1252;LC_MONETARY=English_United
> >> >> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
> >> >>
> >> >> attached base packages:
> >> >> [1] "stats" "graphics" "grDevices" "utils" "datasets"
> "methods" [7]
> >> >> "base"
> >> >> Using EISPACK does NOT return NAs: > sum(is.na(eigen(eigenBug,
> >> >> EISPACK=TRUE)$vectors))
> >> >> [1] 0
> >> >>
> >> >>
> >> >> I traced the problem to the following line in 'eigen':
> >> >> z <- if (!complex.x)
> >> >> .Call("La_rs", x, only.values, PACKAGE = "base")
> >> >>
> >> >>
> >> >> Comments?
> >>
> BDR> Nothing appeared as an attachment.
> >>
> >> it was a zip file which is not among the allowed ones
> >> (.tar.gz / *.tgz would work).
> >>
> >> Spencer has also contacted me in private,
> >> so you now can use something like :
> >>
> >> F <- tempfile()
> >> download.file("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";, F)
> >> load(F)
>
> Duncan> This is unrelated to Spencer's problem, but this
> Duncan> sequence failed for me.
>
> Duncan> By default it will treat the file as a text file,
> Duncan> and convert EOL markers for Windows. Adding
> Duncan> "mode='wb'" to the download.file() call is necessary.
>
> ok; Thank you, Duncan.
>
> {For me, that's yet another reason why I think it would be ``nice''
> if both load() and source() would work with general
> connections the same way as read.table(), and I could just say
>
> load("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";)
> }
>
> >> str(eigenBug)# tons of dinames; get rid of them:
> >> M <- unname(eigenBug)
> >>
> >> sum(is.na(eigen(M)$vectors))
> >> # 0 (for MM, on Linux); '5670' for Spencer
>
> Duncan> I get the same as Spencer in 2.4.1, but zero in
> Duncan> R-devel, in Windows.
>
> ahh, that's good news.
>
> Maybe Spencer could install a revcent version R-devel on his
> Windows machine, and try the example?
>
>
> Duncan> I haven't tried R-patched yet: there were network
> Duncan> problems here this morning, and the build failed.
I just tried it, and it gives the error the same as R 2.4.1.
Duncan Murdoch
>
> Duncan> Duncan Murdoch
>
> >> sum(is.na(eigen(M, EISPACK=TRUE)$vectors))
> >> # 0
> >>
> >> ## Guess about what kind of BLAS/Lapack I'm using :
> >> file.info(list.files(R.home("lib"), full=TRUE))[,1:3]
> >> ##size isdir mode
> >> ## 64-linux-inst/lib/libRblas.so422558 FALSE 755
> >> ## 64-linux-inst/lib/libRlapack.so 3144596 FALSE 755
> >>
> >>
> >> I.e. I don't get any NA's
> >> which shows to me that the bug is most probably in the Lapack -
> >> Version that Spencer's version of R is linked against.
> >>
> >> Martin Maechler, ETH Zurich
>
> __
> 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] eigen returns NAs from a real matrix
On Mon, 19 Mar 2007, Martin Maechler wrote:
>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>> on Mon, 19 Mar 2007 09:01:39 -0400 writes:
>
>Duncan> On 3/19/2007 6:48 AM, Martin Maechler wrote:
>>>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>>>> on Sun, 18 Mar 2007 06:51:58 + (GMT) writes:
>>>
>BDR> On Sat, 17 Mar 2007, Spencer Graves wrote:
>>> >> Hi, All:
>>> >> Attached please find a symmetric, indefinite matrix for which
>>> >> 'eigen(...)$vectors' included NAs:
>>> >>> load("eigenBug.Rdata")
>>> >>> sum(is.na(eigen(eigenBug)$vectors))
>>> >> [1] 5670
>>> >>> sessioninfo()
>>> >> Error: could not find function "sessioninfo"
>>> >>> sessionInfo()
>>> >> R version 2.4.1 (2006-12-18)
>>> >> i386-pc-mingw32
>>> >>
>>> >> locale:
>>> >> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>>> >> States.1252;LC_MONETARY=English_United
>>> >> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>>> >>
>>> >> attached base packages:
>>> >> [1] "stats" "graphics" "grDevices" "utils" "datasets"
> "methods" [7]
>>> >> "base"
>>> >> Using EISPACK does NOT return NAs: > sum(is.na(eigen(eigenBug,
>>> >> EISPACK=TRUE)$vectors))
>>> >> [1] 0
>>> >>
>>> >>
>>> >> I traced the problem to the following line in 'eigen':
>>> >> z <- if (!complex.x)
>>> >> .Call("La_rs", x, only.values, PACKAGE = "base")
>>> >>
>>> >>
>>> >> Comments?
>>>
>BDR> Nothing appeared as an attachment.
>>>
>>> it was a zip file which is not among the allowed ones
>>> (.tar.gz / *.tgz would work).
>>>
>>> Spencer has also contacted me in private,
>>> so you now can use something like :
>>>
>>> F <- tempfile()
>>> download.file("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";, F)
>>> load(F)
>
>Duncan> This is unrelated to Spencer's problem, but this
>Duncan> sequence failed for me.
>
>Duncan> By default it will treat the file as a text file,
>Duncan> and convert EOL markers for Windows. Adding
>Duncan> "mode='wb'" to the download.file() call is necessary.
>
> ok; Thank you, Duncan.
>
> {For me, that's yet another reason why I think it would be ``nice''
> if both load() and source() would work with general
> connections the same way as read.table(), and I could just say
>
> load("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";)
> }
The help page for load() does have an example of using a url() connection
here, and that works in this example on Windows, as does
load(url("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";))
Not so hard, surely? (The reason load() is different is that it can
transparently handle compressed files, unlike read.table.)
>
>>> str(eigenBug)# tons of dinames; get rid of them:
>>> M <- unname(eigenBug)
>>>
>>> sum(is.na(eigen(M)$vectors))
>>> # 0 (for MM, on Linux); '5670' for Spencer
>
>Duncan> I get the same as Spencer in 2.4.1, but zero in
>Duncan> R-devel, in Windows.
>
> ahh, that's good news.
>
> Maybe Spencer could install a revcent version R-devel on his
> Windows machine, and try the example?
My belief is that the LAPACK update has solved this on Windows: it does
not happen on my Linux systems, and does happen in R-patched on Windows.
>Duncan> I haven't tried R-patched yet: there were network
>Duncan> problems here this morning, and the build failed.
>
>Duncan> Duncan Murdoch
>
>>> sum(is.na(eigen(M, EISPACK=TRUE)$vectors))
>>> # 0
>>>
>>> ## Guess about what kind of BLAS/Lapack I'm using :
>>> file.info(list.files(R.home("lib"), full=TRUE))[,1:3]
>>> ##size isdir mode
>>> ## 64-linux-inst/lib/libRblas.so422558 FALSE 755
>>> ## 64-linux-inst/lib/libRlapack.so 3144596 FALSE 755
>>>
>>>
>>> I.e. I don't get any NA's
>>> which shows to me that the bug is most probably in the Lapack -
>>> Version that Spencer's version of R is linked against.
>>>
>>> Martin Maechler, ETH Zurich
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Carriage returns and Sweave output
Dear all,
I have a code chunk in my Rnw file that, when executed, outputs
carriage return characters ('\r') to inform on the progress (e.g.
"sweep 4 of 1024\r"). But Sweave interprets this as a newline
character, and therefore I get countless pages of output in my
vignette where I only really want one line. Any ideas?
Thanks
E
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R4.1: seq.POSIXt, tz="AEST" (PR#9572)
--=_Part_63767_16761935.1174312715444
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I am sorry, "AEST" was wrong. I can't work out what timezone code it is, but
my default timezone here in eastern australia prints as:
> as.POSIXct("1970-01-01", tz="")
[1] "1970-01-01 AUS Eastern Daylight Time"
and that is the one that has repeated dates before 1970.
But I take your point that it is fundamentally a problem with Windows.
--Felix
On 3/19/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>
> Hmm, AEST is not a valid time zone on Windows.
> See ?as.POSIXlt for one of several places where this is documented.
>
> But in any case, the underlying problem is in the OS, and we only try to
> work around it to the best of our knowledge (and that excludes
> undocumented time zones).
>
>
> On Mon, 19 Mar 2007, [EMAIL PROTECTED] wrote:
>
> > Times from seq.POSIXt come out wrong in AEST timezone around Feb 29
> every
> > leap year before 1970 (on Windows XP).
> >
> > According to help(DateTimeClasses), this is handled by "our own C code".
> >
> >> x <- as.POSIXct("1968-02-27") # tz="AEST"
> >> x.gmt <- as.POSIXct("1968-02-27", tz="GMT")
> >> data.frame(
> > GMT=seq(x.gmt, by="day", length=8),
> > byday=seq(x, by="day", length=8),
> > byDST=seq(x, by="DSTday", length=8))
> > GMT byday byDST
> > 1 1968-02-27 1968-02-27 1968-02-27
> > 2 1968-02-28 1968-02-28 1968-02-28
> > 3 1968-02-29 1968-03-01 1968-03-02
> > 4 1968-03-01 1968-03-02 1968-03-02
> > 5 1968-03-02 1968-03-02 1968-03-02
> > 6 1968-03-03 1968-03-03 1968-03-03
> > 7 1968-03-04 1968-03-04 1968-03-04
> > 8 1968-03-05 1968-03-05 1968-03-05
> >
> >> R.version
> > _
> > platform i386-pc-mingw32
> > arch i386
> > os mingw32
> > system i386, mingw32
> > status
> > major 2
> > minor 4.1
> > year 2006
> > month 12
> > day18
> > svn rev40228
> > language R
> > version.string R version 2.4.1 (2006-12-18)
> >
> >
> >
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
>
--=_Part_63767_16761935.1174312715444
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I am sorry, "AEST" was wrong. I can't work out what timezone code
it is, but my default timezone here in eastern australia prints as:>
as.POSIXct("1970-01-01", tz="")[1] "1970-01-01 AUS
Eastern Daylight Time"
and that is the one that has repeated dates before 1970.But I
take your point that it is fundamentally a problem with
Windows.--FelixOn 3/19/07,
Prof Brian Ripley [EMAIL
PROTECTED]> wrote:
Hmm, AEST is not a valid time zone on Windows.See ?as.POSIXlt for one of
several places where this is documented.But in any case, the underlying
problem is in the OS, and we only try towork around it to the best of our
knowledge (and that excludes
undocumented time zones).On Mon, 19 Mar 2007, mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] wrote:> Times
from seq.POSIXt come out wrong in AEST timezone around Feb 29 every>
leap year before 1970 (on Windows XP).
>> According to help(DateTimeClasses), this is handled by
"our own C code".>>> x <-
as.POSIXct("1968-02-27") # tz="AEST">> x.gmt
<- as.POSIXct("1968-02-27", tz="GMT")
>> data.frame(> GMT=seq(x.gmt,
by="day", length=8),> byday=seq(x,
by="day", length=8),> byDST=seq(x,
by="DSTday",
length=8))>
GMT byday byDST
> 1 1968-02-27 1968-02-27 1968-02-27> 2 1968-02-28 1968-02-28
1968-02-28> 3 1968-02-29 1968-03-01 1968-03-02> 4 1968-03-01
1968-03-02 1968-03-02> 5 1968-03-02 1968-03-02 1968-03-02> 6
1968-03-03 1968-03-03 1968-03-03
> 7 1968-03-04 1968-03-04 1968-03-04> 8 1968-03-05 1968-03-05
1968-03-05>>>
R.version>
_> platform i386-pc-mingw32>
arch i386>
os
mingw32
> system i386,
mingw32> status>
major 2>
minor 4.1>
year 2006>
month 12>
day18>
svn rev40228>
language R
> version.string R version 2.4.1
(2006-12-18)--Brian D.
Ripley, mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]Professor of Applied
Statistics,
http://www.stats.ox.ac.uk/~ripley/";>http://www.stats.ox.ac.uk/~ripley/University
of
Oxford,
Tel: +44 1865 272861 (self)1 South Parks
Road,
+44 1865 272866 (PA)Oxford OX1 3TG,
UKFax: +44
1865 272595
--=_Part_63767_16761935.1174312715444--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listin
[Rd] R CMD Rd2dvi
Hello perhaps this is a bit late for R-2.5.0, but does anyone find R CMD Rd2dvi refusing to overwrite an existing dvi file useful? I am forever leaving the .dvi file in my scratch directory and have to remove it manually. I know that one can specify --output=f.dvi, but this just defers the problem because f.dvi won't be overwritten either. Does anyone value this behaviour? If not, could we change it? For me, the typical session goes: octopus:~/scratch% R CMD Rd2dvi ./BACCO Hmm ... looks like a package bundle file 'BACCO.dvi' exists; please remove first octopus:~/scratch% rm BACCO.dvi octopus:~/scratch% R CMD Rd2dvi ./BACCO Hmm ... looks like a package bundle [snip]. -- Robin Hankin Uncertainty Analyst 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] eigen returns NAs from a real matrix
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Mon, 19 Mar 2007 13:37:15 + (GMT) writes:
BDR> On Mon, 19 Mar 2007, Martin Maechler wrote:
>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>>> on Mon, 19 Mar 2007 09:01:39 -0400 writes:
>>
Duncan> On 3/19/2007 6:48 AM, Martin Maechler wrote:
>> >>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>> >>> on Sun, 18 Mar 2007 06:51:58 + (GMT) writes:
>> >>
BDR> On Sat, 17 Mar 2007, Spencer Graves wrote:
>> >> >> Hi, All:
>> >> >> Attached please find a symmetric, indefinite matrix for which
>> >> >> 'eigen(...)$vectors' included NAs:
>> >> >>> load("eigenBug.Rdata")
>> >> >>> sum(is.na(eigen(eigenBug)$vectors))
>> >> >> [1] 5670
>> >> >>> sessioninfo()
>> >> >> Error: could not find function "sessioninfo"
>> >> >>> sessionInfo()
>> >> >> R version 2.4.1 (2006-12-18)
>> >> >> i386-pc-mingw32
>> >> >>
>> >> >> locale:
>> >> >> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> >> >> States.1252;LC_MONETARY=English_United
>> >> >> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>> >> >>
>> >> >> attached base packages:
>> >> >> [1] "stats" "graphics" "grDevices" "utils" "datasets"
"methods" [7]
>> >> >> "base"
>> >> >> Using EISPACK does NOT return NAs: > sum(is.na(eigen(eigenBug,
>> >> >> EISPACK=TRUE)$vectors))
>> >> >> [1] 0
>> >> >>
>> >> >>
>> >> >> I traced the problem to the following line in 'eigen':
>> >> >> z <- if (!complex.x)
>> >> >> .Call("La_rs", x, only.values, PACKAGE = "base")
>> >> >>
>> >> >>
>> >> >> Comments?
>> >>
BDR> Nothing appeared as an attachment.
>> >>
>> >> it was a zip file which is not among the allowed ones
>> >> (.tar.gz / *.tgz would work).
>> >>
>> >> Spencer has also contacted me in private,
>> >> so you now can use something like :
>> >>
>> >> F <- tempfile()
>> >> download.file("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";, F)
>> >> load(F)
>>
Duncan> This is unrelated to Spencer's problem, but this
Duncan> sequence failed for me.
>>
Duncan> By default it will treat the file as a text file,
Duncan> and convert EOL markers for Windows. Adding
Duncan> "mode='wb'" to the download.file() call is necessary.
>>
>> ok; Thank you, Duncan.
>>
>> {For me, that's yet another reason why I think it would be ``nice''
>> if both load() and source() would work with general
>> connections the same way as read.table(), and I could just say
>>
>> load("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";)
>> }
BDR> The help page for load() does have an example of using a url()
connection
BDR> here, and that works in this example on Windows, as does
BDR> load(url("ftp://stat.ethz.ch/U/maechler/R/eigenBug.Rdata";))
BDR> Not so hard, surely?
definitely not. Here, I've confused load() and source()
and just last week in a course I gave I had wished that I could
use
source(url())
BDR> (The reason load() is different is that it can transparently handle
compressed files, unlike read.table.)
yes, indeed; I had forgotten about the reason.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Carriage returns and Sweave output
Dear Ernest,
this may not be exactly what you asked for, but how about setting
"results=hide" in the options of your code chunk?
Best wishes
Wolfgang
--
Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber
Ernest Turro wrote:
> Dear all,
>
> I have a code chunk in my Rnw file that, when executed, outputs
> carriage return characters ('\r') to inform on the progress (e.g.
> "sweep 4 of 1024\r"). But Sweave interprets this as a newline
> character, and therefore I get countless pages of output in my
> vignette where I only really want one line. Any ideas?
>
> Thanks
>
> E
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Carriage returns and Sweave output
Hi Wolfgang,
the problem with results=hide is that it suppresses everything. I
just need Sweave to suppress strings ending in '\r'...
Best,
Ernest
On 19 Mar 2007, at 14:49, Wolfgang Huber wrote:
> Dear Ernest,
>
> this may not be exactly what you asked for, but how about setting
> "results=hide" in the options of your code chunk?
>
> Best wishes
> Wolfgang
>
> --
> Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber
>
> Ernest Turro wrote:
>> Dear all,
>> I have a code chunk in my Rnw file that, when executed, outputs
>> carriage return characters ('\r') to inform on the progress (e.g.
>> "sweep 4 of 1024\r"). But Sweave interprets this as a newline
>> character, and therefore I get countless pages of output in my
>> vignette where I only really want one line. Any ideas?
>> Thanks
>> E
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Incomplete valgrind instrumentation level documentation
On Fri, 16 Mar 2007, Martin Morgan wrote: > The 'Writing R Extensions' manual, configure.ac, and the comment at > the top of memory.c suggests that there are valgrind instrumentation > levels 0, 1, 2 but I think the actual code has four levels. Yes, but only three of them work. Those are the ones that are documented. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Invalidating inaccessible SEXP?
On Fri, 16 Mar 2007, Martin Morgan wrote: > Is there a (C or R) function to invalidate the relevant parts of SEXP > / data that are inaccessible? My problem is in tracking down > protection and other memory mismanagement bugs, where I have to rely > on luck to invalidate or overwrite data to trigger a detectable > error. This makes it hard to track down a bug (it sometimes doesn't > occur), or to know that a patch fixes the problem. > Under Valgrind when R is compiled --with-valgrind-instrumentation=2 the code walks the list of newly freed SEXPs and marks them as inaccessible (which is one reason why it is so slow). I don't know of any other facilities to do what you want. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Carriage returns and Sweave output
> the problem with results=hide is that it suppresses everything. I just
> need Sweave to suppress strings ending in '\r'...
Dear Ernest,
IMHO it is good practice to make the printing of these progress reports
("sweep 4 of 1024\r") optional and produce them only if the user calls
your function with, say, "verbose=TRUE", and furthermore set the default
value of the 'verbose' argument to "verbose=interactive()".
Best wishes
Wolfgang
> On 19 Mar 2007, at 14:49, Wolfgang Huber wrote:
>
>> Dear Ernest,
>>
>> this may not be exactly what you asked for, but how about setting
>> "results=hide" in the options of your code chunk?
>>
>> Best wishes
>> Wolfgang
>>
>> --
>> Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber
>>
>> Ernest Turro wrote:
>>> Dear all,
>>> I have a code chunk in my Rnw file that, when executed, outputs
>>> carriage return characters ('\r') to inform on the progress (e.g.
>>> "sweep 4 of 1024\r"). But Sweave interprets this as a newline
>>> character, and therefore I get countless pages of output in my
>>> vignette where I only really want one line. Any ideas?
>>> Thanks
>>> E
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Carriage returns and Sweave output
Ernest Turro <[EMAIL PROTECTED]> writes: > Hi Wolfgang, > > the problem with results=hide is that it suppresses everything. I > just need Sweave to suppress strings ending in '\r'... Perhaps another idea is to add a verbose=FALSE option to the function that spews \r. In general, any status output of calculation should be optional since they can get in the way of things like Sweave, etc. -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] free variable, built-in R functions
Hi, I have one question about built-in R functions. I am looking into interprocedural analysis and since R supports "free variable", it would become complicated if free variable is read inside a function. It is uncommon and probably not good to read free variables when implementing R functions. I suppose R built-in functions don't read free variables (therefore don't depend on global variables). Could someone in the development team confirm about that? Thank you very much. Best regards, Jiangtian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] build 2.4.1 for AIX 5.2L
nobody tested it in xlf. but was able to build it in gcc. when link as main, export is necessary by all means. I put patch. http://prs.ism.ac.jp/%7enakama/AIX/ I am happy if useful. -- EI-JI Nakama <[EMAIL PROTECTED]> "\u4e2d\u9593\u6804\u6cbb" <[EMAIL PROTECTED]> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check ignores .Rbuildignore?
On Mon, Mar 19, 2007 at 11:33:37AM +0100, Martin Maechler wrote: > > "RossB" == Ross Boylan <[EMAIL PROTECTED]> > > on Sun, 18 Mar 2007 12:39:14 -0700 writes: > > RossB> The contents of .Rbuildignore seems to affect > RossB> R CMD build > RossB> but not > RossB> R CMD check. > > RossB> I'm using R 2.4.0 on Debian. > > RossB> Is my understanding correct? > > yes. That's why it's called 'buildignore'. > It's a big feature for me as package developer: It's more of a bug for me :(. I was thinking of check as answering the question "If I build this package, will it work?" > > E.g., I can have extra tests (which e.g. only apply on my > specific platform) in addition to those which are use when the > package is built (to be checked on all possible platforms). > > Some have proposed to additionally define a '.Rcheckignore' > but they haven't been convincing enough. How about an option to have check use the buildignore file? If there are 2 separate files, there's always the risk they will get out of sync. Of course, in your case, you want them out of sync... > > RossB> And is there anything I can do about it? > > "First build, then check" is one way; > Something which is recommended anyway in some cases, > e.g., if you have an (Sweave - based) vignette. Kurt Hornick, offlist, also advised this, as well as noting that using R CMD check directly on the main development directory isn't really supported. >From my perspective, needing to do a build before a check is extra friction, which would reduce the amount of checking I do during development. Also, doesn't build do some of the same checks as check? Minimally, I think some advice in the R Extensions manual needs to be qualified: In 1.3 Checking and building packages == Before using these tools, please check that your package can be installed and loaded. `R CMD check' will _inter alia_ do this, but you will get more informative error messages doing the checks directly. --- There seem to be a couple of problems with this advice, aside from the fact that it says to check first. One problem is that the advice seems internally inconsistent. "Before using these tools" seems to refer to the build and check tools in the section. Since check is one of the tools, it can't be used before using the tools. Also, I still can't figure out what "doing the checks directly" refers to. Another section: 1.3.2 Building packages --- [2 paragraphs skipped] Run-time checks whether the package works correctly should be performed using `R CMD check' prior to invoking the build procedure. Since this advice, check then build, is the exact opposite of the current recommendations, build then check, it probably needs to be changed. R CMD check --help (and other spots) refer to the command as "Check R packages from package sources, which can be directories or gzipped package 'tar' archives with extension '.tar.gz' or '.tgz'." I read this as referring to my source directory, although I guess other readings are possible (i.e., package source = the source bundle as distributed). > > RossB> In my case, some of the excluded files contain references to other > RossB> libraries, so linking fails under R CMD check. I realize I could > add > RossB> the library to the build (with Makevars, I guess), but I do not > want > RossB> to introduce the dependency. > > It depends on the circumstances on how I would solve this > problem > [Why have these files as part of the package sources at all?] I have 2 kinds of checks, those at the R level, which get executed as part of R CMD check, and C++ unit tests, which I execute separately. The latter use the boost test library, part of which is a link-time library that ordinary users should not need. All the C++ sources come from a web (as in Knuth's web) file, so the main files and the testing files all get produced at once. I worked around the problem by using the top level config script to delete the test files. I suppose I could also look into moving those files into another directory when they are produced, but that would further complicate my build system. Ross __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check ignores .Rbuildignore? [correction]
On Mon, Mar 19, 2007 at 10:38:02AM -0700, Ross Boylan wrote: > Kurt Hornick, offlist, also advised this, as well as noting that using Sorry. That should be "Kurt Hornik." Ross __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check ignores .Rbuildignore?
On 3/19/07, Ross Boylan <[EMAIL PROTECTED]> wrote: > How about an option to have check use the buildignore file? If there > are 2 separate files, there's always the risk they will get out of > sync. Of course, in your case, you want them out of sync... For Windows users only there is a batch file, makepkg.bat, in the batchfiles distribution that will run a build prior to a check or install so that .Rbuildignore gets invoked. It would be possible to create a similar shell file for UNIX. http://code.google.com/p/batchfiles/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] -std=c99 and inline semantics
Hi, I noticed that with the GCC trunk (4.3.0), the semantics of "extern inline" have reversed. The net result is that R will build without the usual-stdc=gnu99 but it won't with it. Many multiple definitions result otherwise. Marcus __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rinternals.h and undefined symbols
Hi, I'm trying to register my native routines using R_registerRoutines (...). I can compile the code, but the loader cannot resolve the symbol: undefined symbol: _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3_S6 _ $ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines U _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3_S6 _ Why does it have this funny name? If I look at libR.so, I get an ordinary symbol name: $ nm ~/lib64/R/lib/libR.so | grep R_registerRoutines 00032f80 T R_registerRoutines I get normal symbol names for R functions not in Rinternals.h and there is no problem there. For example: nm bgx.Rcheck/bgx/libs/bgx.so | grep Rprintf U Rprintf $ nm ~/lib64/R/lib/libR.so | grep Rprintf 00129690 T Rprintf The shared library dependencies are also fine: $ ldd bgx.Rcheck/bgx/libs/bgx.so libR.so => /home/et04/lib64/R/lib/libR.so (0x002a95676000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x002a95a8) libm.so.6 => /lib64/tls/libm.so.6 (0x002a95c7) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x002a95df7000) libc.so.6 => /lib64/tls/libc.so.6 (0x002a95f02000) libRblas.so => /home/et04/lib64/R/lib/libRblas.so (0x002a96136000) libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x002a96262000) libreadline.so.4 => /usr/lib64/libreadline.so.4 (0x002a96383000) libncurses.so.5 => /usr/lib64/libncurses.so.5 (0x002a964bc000) libdl.so.2 => /lib64/libdl.so.2 (0x002a96618000) /lib64/ld-linux-x86-64.so.2 (0x00552000) My LD_LIBRARY_PATH environmental variable is set appropriately. Any ideas? Thanks, E __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rinternals.h and undefined symbols
On 3/19/2007 5:23 PM, Ernest Turro wrote:
> Hi,
>
> I'm trying to register my native routines using R_registerRoutines
> (...). I can compile the code, but the loader cannot resolve the symbol:
>
> undefined symbol:
> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3_S6
> _
>
> $ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines
> U
> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3_S6
> _
>
> Why does it have this funny name? If I look at libR.so, I get an
> ordinary symbol name:
That looks like C++ name mangling. Are you wrapping your declarations in
extern "C" { }
?
Duncan Murdoch
>
> $ nm ~/lib64/R/lib/libR.so | grep R_registerRoutines
> 00032f80 T R_registerRoutines
>
> I get normal symbol names for R functions not in Rinternals.h and
> there is no problem there. For example:
>
> nm bgx.Rcheck/bgx/libs/bgx.so | grep Rprintf
> U Rprintf
>
> $ nm ~/lib64/R/lib/libR.so | grep Rprintf
> 00129690 T Rprintf
>
> The shared library dependencies are also fine:
>
> $ ldd bgx.Rcheck/bgx/libs/bgx.so
> libR.so => /home/et04/lib64/R/lib/libR.so (0x002a95676000)
> libstdc++.so.6 => /usr/lib64/libstdc++.so.6
> (0x002a95a8)
> libm.so.6 => /lib64/tls/libm.so.6 (0x002a95c7)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x002a95df7000)
> libc.so.6 => /lib64/tls/libc.so.6 (0x002a95f02000)
> libRblas.so => /home/et04/lib64/R/lib/libRblas.so
> (0x002a96136000)
> libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x002a96262000)
> libreadline.so.4 => /usr/lib64/libreadline.so.4
> (0x002a96383000)
> libncurses.so.5 => /usr/lib64/libncurses.so.5
> (0x002a964bc000)
> libdl.so.2 => /lib64/libdl.so.2 (0x002a96618000)
> /lib64/ld-linux-x86-64.so.2 (0x00552000)
>
> My LD_LIBRARY_PATH environmental variable is set appropriately.
>
> Any ideas?
>
> Thanks,
>
> E
>
> __
> 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] Rinternals.h and undefined symbols
On 19 Mar 2007, at 21:32, Duncan Murdoch wrote:
> On 3/19/2007 5:23 PM, Ernest Turro wrote:
>> Hi,
>> I'm trying to register my native routines using R_registerRoutines
>> (...). I can compile the code, but the loader cannot resolve the
>> symbol:
>> undefined symbol:
>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3
>> _S6 _
>> $ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines
>> U
>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDefS3
>> _S6 _
>> Why does it have this funny name? If I look at libR.so, I get an
>> ordinary symbol name:
>
> That looks like C++ name mangling. Are you wrapping your
> declarations in
>
> extern "C" { }
>
> ?
Yeah, the routine is literally just:
extern "C"
void R_init_bgx(DllInfo *info) {
R_registerRoutines(info, cMethods,NULL,NULL,NULL);
}
with cMethods declared outside as a static const R_CMethodDef.
The two routines that I am registering are also wrapped in extern "C".
Ernest
>
> Duncan Murdoch
>
>
>> $ nm ~/lib64/R/lib/libR.so | grep R_registerRoutines
>> 00032f80 T R_registerRoutines
>> I get normal symbol names for R functions not in Rinternals.h and
>> there is no problem there. For example:
>> nm bgx.Rcheck/bgx/libs/bgx.so | grep Rprintf
>> U Rprintf
>> $ nm ~/lib64/R/lib/libR.so | grep Rprintf
>> 00129690 T Rprintf
>> The shared library dependencies are also fine:
>> $ ldd bgx.Rcheck/bgx/libs/bgx.so
>> libR.so => /home/et04/lib64/R/lib/libR.so
>> (0x002a95676000)
>> libstdc++.so.6 => /usr/lib64/libstdc++.so.6
>> (0x002a95a8)
>> libm.so.6 => /lib64/tls/libm.so.6 (0x002a95c7)
>> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x002a95df7000)
>> libc.so.6 => /lib64/tls/libc.so.6 (0x002a95f02000)
>> libRblas.so => /home/et04/lib64/R/lib/libRblas.so
>> (0x002a96136000)
>> libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x002a96262000)
>> libreadline.so.4 => /usr/lib64/libreadline.so.4
>> (0x002a96383000)
>> libncurses.so.5 => /usr/lib64/libncurses.so.5
>> (0x002a964bc000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x002a96618000)
>> /lib64/ld-linux-x86-64.so.2 (0x00552000)
>> My LD_LIBRARY_PATH environmental variable is set appropriately.
>> Any ideas?
>> Thanks,
>> E
>> __
>> 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] Rinternals.h and undefined symbols
On 20 Mar 2007, at 00:18, Duncan Murdoch wrote:
> On 3/19/2007 7:41 PM, Ernest Turro wrote:
>> On 19 Mar 2007, at 21:32, Duncan Murdoch wrote:
>>> On 3/19/2007 5:23 PM, Ernest Turro wrote:
Hi,
I'm trying to register my native routines using
R_registerRoutines (...). I can compile the code, but the
loader cannot resolve the symbol:
undefined symbol:
_Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDef
S3 _S6 _
$ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines
U
_Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodDef
S3 _S6 _
Why does it have this funny name? If I look at libR.so, I get
an ordinary symbol name:
>>> That looks like C++ name mangling. Are you wrapping your
>>> declarations in
>>>
>>> extern "C" { }
>>>
>>> ?
>> Yeah, the routine is literally just:
>> extern "C"
>>void R_init_bgx(DllInfo *info) {
>> R_registerRoutines(info, cMethods,NULL,NULL,NULL);
>>}
>> with cMethods declared outside as a static const R_CMethodDef.
>
> I'm no C++ expert, but that looks like it declares R_init_bgx to be
> a "C" routine, but not R_registerRoutines (which is what the error
> was about). Its declaration is in Rdynload.h:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
> int R_registerRoutines(DllInfo *info, const R_CMethodDef * const
> croutines,
> const R_CallMethodDef * const callRoutines,
> const R_FortranMethodDef * const fortranRoutines,
>const R_ExternalMethodDef * const
> externalRoutines);
>
> Rboolean R_useDynamicSymbols(DllInfo *info, Rboolean value);
> #ifdef __cplusplus
> }
> #endif
>
> so maybe your compiler doesn't define __cplusplus, or you didn't
> include R_ext/Rdynload.h?
Thanks for the reply.
__cplusplus is defined and I do #include (after
all, it does compile)...
I've tried this on two different machines, so it's not a problem
specific to my setup either... ):
Ernest
>
> Duncan Murdoch
>
>
>> The two routines that I am registering are also wrapped in extern
>> "C".
>> Ernest
>>> Duncan Murdoch
>>>
>>>
$ nm ~/lib64/R/lib/libR.so | grep R_registerRoutines
00032f80 T R_registerRoutines
I get normal symbol names for R functions not in Rinternals.h
and there is no problem there. For example:
nm bgx.Rcheck/bgx/libs/bgx.so | grep Rprintf
U Rprintf
$ nm ~/lib64/R/lib/libR.so | grep Rprintf
00129690 T Rprintf
The shared library dependencies are also fine:
$ ldd bgx.Rcheck/bgx/libs/bgx.so
libR.so => /home/et04/lib64/R/lib/libR.so
(0x002a95676000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6
(0x002a95a8)
libm.so.6 => /lib64/tls/libm.so.6 (0x002a95c7)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x002a95df7000)
libc.so.6 => /lib64/tls/libc.so.6 (0x002a95f02000)
libRblas.so => /home/et04/lib64/R/lib/libRblas.so
(0x002a96136000)
libg2c.so.0 => /usr/lib64/libg2c.so.0 (0x002a96262000)
libreadline.so.4 => /usr/lib64/libreadline.so.4
(0x002a96383000)
libncurses.so.5 => /usr/lib64/libncurses.so.5
(0x002a964bc000)
libdl.so.2 => /lib64/libdl.so.2 (0x002a96618000)
/lib64/ld-linux-x86-64.so.2 (0x00552000)
My LD_LIBRARY_PATH environmental variable is set appropriately.
Any ideas?
Thanks,
E
__
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] Rinternals.h and undefined symbols
On 20 Mar 2007, at 00:50, Duncan Murdoch wrote:
> On 3/19/2007 8:41 PM, Ernest Turro wrote:
>> On 20 Mar 2007, at 00:18, Duncan Murdoch wrote:
>>> On 3/19/2007 7:41 PM, Ernest Turro wrote:
On 19 Mar 2007, at 21:32, Duncan Murdoch wrote:
> On 3/19/2007 5:23 PM, Ernest Turro wrote:
>> Hi,
>> I'm trying to register my native routines using
>> R_registerRoutines (...). I can compile the code, but the
>> loader cannot resolve the symbol:
>> undefined symbol:
>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodD
>> ef S3 _S6 _
>> $ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines
>> U
>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodD
>> ef S3 _S6 _
>> Why does it have this funny name? If I look at libR.so, I get
>> an ordinary symbol name:
> That looks like C++ name mangling. Are you wrapping your
> declarations in
>
> extern "C" { }
>
> ?
Yeah, the routine is literally just:
extern "C"
void R_init_bgx(DllInfo *info) {
R_registerRoutines(info, cMethods,NULL,NULL,NULL);
}
with cMethods declared outside as a static const R_CMethodDef.
>>> I'm no C++ expert, but that looks like it declares R_init_bgx to
>>> be a "C" routine, but not R_registerRoutines (which is what the
>>> error was about). Its declaration is in Rdynload.h:
>>>
>>> #ifdef __cplusplus
>>> extern "C" {
>>> #endif
>>> int R_registerRoutines(DllInfo *info, const R_CMethodDef * const
>>> croutines,
>>>const R_CallMethodDef * const callRoutines,
>>>const R_FortranMethodDef * const fortranRoutines,
>>>const R_ExternalMethodDef * const
>>> externalRoutines);
>>>
>>> Rboolean R_useDynamicSymbols(DllInfo *info, Rboolean value);
>>> #ifdef __cplusplus
>>> }
>>> #endif
>>>
>>> so maybe your compiler doesn't define __cplusplus, or you didn't
>>> include R_ext/Rdynload.h?
Duncan, you hit the nail on the head. Thanks so much.
If you download R-2.4.1.tar.gz from CRAN you will find that the
extern "C" is missing in Rdynload.h! I added it to my copy and my
code compiles now. I wonder why it's missing. Has this been fixed in
cvs?
Thanks,
Ernest
PS. you don't need the braces after extern "C"
>> Thanks for the reply.
>> __cplusplus is defined and I do #include
>> (after all, it does compile)...
>> I've tried this on two different machines, so it's not a problem
>> specific to my setup either... ):
>
> Here I'm just guessing: you don't wrap the whole function in
> extern "C", you just put extern "C" ahead of its header. That's not
> the usual way it's done, but I don't know C++ well enough to know
> if it matters. Nevertheless, I'd try
>
> extern "C" {
> void R_init_bgx(DllInfo *info) {
> R_registerRoutines(info, cMethods,NULL,NULL,NULL);
> }
> }
>
> just to see if it helps.
>
> Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rinternals.h and undefined symbols
On 3/19/2007 8:55 PM, Ernest Turro wrote:
> On 20 Mar 2007, at 00:50, Duncan Murdoch wrote:
>
>> On 3/19/2007 8:41 PM, Ernest Turro wrote:
>>> On 20 Mar 2007, at 00:18, Duncan Murdoch wrote:
On 3/19/2007 7:41 PM, Ernest Turro wrote:
> On 19 Mar 2007, at 21:32, Duncan Murdoch wrote:
>> On 3/19/2007 5:23 PM, Ernest Turro wrote:
>>> Hi,
>>> I'm trying to register my native routines using
>>> R_registerRoutines (...). I can compile the code, but the
>>> loader cannot resolve the symbol:
>>> undefined symbol:
>>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodD
>>> ef S3 _S6 _
>>> $ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines
>>> U
>>> _Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodD
>>> ef S3 _S6 _
>>> Why does it have this funny name? If I look at libR.so, I get
>>> an ordinary symbol name:
>> That looks like C++ name mangling. Are you wrapping your
>> declarations in
>>
>> extern "C" { }
>>
>> ?
> Yeah, the routine is literally just:
> extern "C"
>void R_init_bgx(DllInfo *info) {
> R_registerRoutines(info, cMethods,NULL,NULL,NULL);
>}
> with cMethods declared outside as a static const R_CMethodDef.
I'm no C++ expert, but that looks like it declares R_init_bgx to
be a "C" routine, but not R_registerRoutines (which is what the
error was about). Its declaration is in Rdynload.h:
#ifdef __cplusplus
extern "C" {
#endif
int R_registerRoutines(DllInfo *info, const R_CMethodDef * const
croutines,
const R_CallMethodDef * const callRoutines,
const R_FortranMethodDef * const fortranRoutines,
const R_ExternalMethodDef * const
externalRoutines);
Rboolean R_useDynamicSymbols(DllInfo *info, Rboolean value);
#ifdef __cplusplus
}
#endif
so maybe your compiler doesn't define __cplusplus, or you didn't
include R_ext/Rdynload.h?
>
>
> Duncan, you hit the nail on the head. Thanks so much.
>
> If you download R-2.4.1.tar.gz from CRAN you will find that the
> extern "C" is missing in Rdynload.h! I added it to my copy and my
> code compiles now. I wonder why it's missing. Has this been fixed in
> cvs?
Yes, it's a new addition Duncan Temple Lang added in November. I didn't
remember that or I would have mentioned it.
Duncan Murdoch
> Thanks,
>
> Ernest
>
> PS. you don't need the braces after extern "C"
>
>
>
>>> Thanks for the reply.
>>> __cplusplus is defined and I do #include
>>> (after all, it does compile)...
>>> I've tried this on two different machines, so it's not a problem
>>> specific to my setup either... ):
>> Here I'm just guessing: you don't wrap the whole function in
>> extern "C", you just put extern "C" ahead of its header. That's not
>> the usual way it's done, but I don't know C++ well enough to know
>> if it matters. Nevertheless, I'd try
>>
>> extern "C" {
>> void R_init_bgx(DllInfo *info) {
>> R_registerRoutines(info, cMethods,NULL,NULL,NULL);
>> }
>> }
>>
>> just to see if it helps.
>>
>> Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rinternals.h and undefined symbols
Note though that you should include C header files inside extern "C" in
your C++ code. 'Writing R Extensions' says
Some @R{} header files are C and not C++ header files and should be
included within an @code{extern "C"} block: for clarity this is
advisable for all @R{} header files.
On Mon, 19 Mar 2007, Duncan Murdoch wrote:
> On 3/19/2007 8:55 PM, Ernest Turro wrote:
>> On 20 Mar 2007, at 00:50, Duncan Murdoch wrote:
>>
>>> On 3/19/2007 8:41 PM, Ernest Turro wrote:
On 20 Mar 2007, at 00:18, Duncan Murdoch wrote:
> On 3/19/2007 7:41 PM, Ernest Turro wrote:
>> On 19 Mar 2007, at 21:32, Duncan Murdoch wrote:
>>> On 3/19/2007 5:23 PM, Ernest Turro wrote:
Hi,
I'm trying to register my native routines using
R_registerRoutines (...). I can compile the code, but the
loader cannot resolve the symbol:
undefined symbol:
_Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodD
ef S3 _S6 _
$ nm bgx.Rcheck/bgx/libs/bgx.so | grep R_registerRoutines
U
_Z18R_registerRoutinesP8_DllInfoPK12R_CMethodDefPK15R_CallMethodD
ef S3 _S6 _
Why does it have this funny name? If I look at libR.so, I get
an ordinary symbol name:
>>> That looks like C++ name mangling. Are you wrapping your
>>> declarations in
>>>
>>> extern "C" { }
>>>
>>> ?
>> Yeah, the routine is literally just:
>> extern "C"
>>void R_init_bgx(DllInfo *info) {
>> R_registerRoutines(info, cMethods,NULL,NULL,NULL);
>>}
>> with cMethods declared outside as a static const R_CMethodDef.
> I'm no C++ expert, but that looks like it declares R_init_bgx to
> be a "C" routine, but not R_registerRoutines (which is what the
> error was about). Its declaration is in Rdynload.h:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
> int R_registerRoutines(DllInfo *info, const R_CMethodDef * const
> croutines,
> const R_CallMethodDef * const callRoutines,
> const R_FortranMethodDef * const fortranRoutines,
>const R_ExternalMethodDef * const
> externalRoutines);
>
> Rboolean R_useDynamicSymbols(DllInfo *info, Rboolean value);
> #ifdef __cplusplus
> }
> #endif
>
> so maybe your compiler doesn't define __cplusplus, or you didn't
> include R_ext/Rdynload.h?
>>
>>
>> Duncan, you hit the nail on the head. Thanks so much.
>>
>> If you download R-2.4.1.tar.gz from CRAN you will find that the
>> extern "C" is missing in Rdynload.h! I added it to my copy and my
>> code compiles now. I wonder why it's missing. Has this been fixed in
>> cvs?
>
> Yes, it's a new addition Duncan Temple Lang added in November. I didn't
> remember that or I would have mentioned it.
>
> Duncan Murdoch
>
>> Thanks,
>>
>> Ernest
>>
>> PS. you don't need the braces after extern "C"
>>
>>
>>
Thanks for the reply.
__cplusplus is defined and I do #include
(after all, it does compile)...
I've tried this on two different machines, so it's not a problem
specific to my setup either... ):
>>> Here I'm just guessing: you don't wrap the whole function in
>>> extern "C", you just put extern "C" ahead of its header. That's not
>>> the usual way it's done, but I don't know C++ well enough to know
>>> if it matters. Nevertheless, I'd try
>>>
>>> extern "C" {
>>> void R_init_bgx(DllInfo *info) {
>>> R_registerRoutines(info, cMethods,NULL,NULL,NULL);
>>> }
>>> }
>>>
>>> just to see if it helps.
>>>
>>> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Carriage returns and Sweave output
> "Wolfi" == Wolfgang Huber <[EMAIL PROTECTED]>
> on Mon, 19 Mar 2007 15:38:00 + writes:
>> the problem with results=hide is that it suppresses everything. I just
>> need Sweave to suppress strings ending in '\r'...
Wolfi> Dear Ernest,
Wolfi> IMHO it is good practice to make the printing of these progress
reports
Wolfi> ("sweep 4 of 1024\r") optional and produce them only if the user
calls
Wolfi> your function with, say, "verbose=TRUE",
I strongly agree.
Wolfi> and furthermore set the default value of the
Wolfi> 'verbose' argument to "verbose=interactive()".
or -- typically my choice -- to 'verbose = getOption("verbose")
Martin Maechler, ETH Zurich
Wolfi> Best wishes
Wolfi> Wolfgang
[]
>>> Ernest Turro wrote:
Dear all,
I have a code chunk in my Rnw file that, when executed, outputs
carriage return characters ('\r') to inform on the progress (e.g.
"sweep 4 of 1024\r"). But Sweave interprets this as a newline
character, and therefore I get countless pages of output in my
vignette where I only really want one line. Any ideas?
Thanks
E
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
