headers
Jeffrey Ryan | 22 May 22:31
Picon

Capturing signals from within external libs

I have a continuous loop running in an external library that I am calling
from C (R API).  This loop is processing events in real time with the
possibility of significant lag between events.

When processing an event, I can make use of R_CheckUserInterrupt, but
while the external library code is waiting on a new event, I don't have an
opportunity to call this - my entry points are only on events.

I can capture a SIGINT by redefining signal(SIGINT, myhandler) before
calling the lib, but I am somewhat at a loss in terms of what I can do
within the handler that would let me pass control back to R.

void myhandler (int s) {
  error("interrupt caught!");
}

Works, but I am sure it isn't supposed to.  In fact I know it is wrong,
since after interrupting once SIGINTs are subsequently ignored, even if I
reset the signal to the original one (as returned by the first call to
signal).

Currently I can exit(1) of course, but that is tragically bad form IMO,
though will work in my situation.

In short, what is the proper way to handle SIGINT in external code that is
called from R, that allows R to handle the signal.  Thoughts or
suggestions appreciated.

Thanks,
Jeff
(Continue reading)

Permalink | Reply | 1 comment |
headers
Henrik Bengtsson | 22 May 19:34
Picon

Best way to locate R executable from within R?

Hi,

I'd like to spawn of a new R process from within R using system(),
e.g. system("R -f myScript.R").  However, just specifying "R" as in
that example is not guaranteed to work, because "R" may not be on the
OS's search path.

 What is the best way, from within a running R, to infer the command
(basename or full path) for launching R in way that it works on any
OS?  I came up with the following alternatives, but I'm not sure if
they'll work everywhere or not:

1. Rbin <- commandArgs()[1];

2. Rbin <- file.path(R.home(), "bin", "R");

Other suggestions that are better?

/Henrik
Permalink | Reply | 13 comments |
headers
Richard Cotton | 22 May 18:26
Picon
Gravatar

Codoc mismatch for roxygen-documented foo<- functions

I have a roxygen2 documented package with functions for getting and
setting an attribute.

#' Get or set the foo attribute.
#'
#' Dummy function!
#'
#' @param x Object to hold the attribute.
#' @param value Value to set the attribute to.
#' @return The get function returns the "foo" attribute of \code{x}.
#' @export
foo <- function(x)
{
  attr(x, "foo")
}

#' @rdname foo
#' @export
`foo<-` <- function(x, value)
{
  attr(x, "foo") <- value
}

If I save the above to foo.R and then do

library(roxygen2)
library(devtools)
package.skeleton("foo", code_files="foo.R")
roxygenize("foo")
check("foo")
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joan Maspons | 22 May 12:14

Patch to add Beta binomial distribution. Mentor needed!

Hello,

I implemented the Beta binomial distribution following the patterns of the
binomial distribution code and inspired by JAGS' code [1]. I have studied
the code carefully but it's my first run in the R internals.

Can somebody review the code and if everything it's ok commit to the
repository?

[1]
http://mcmc-jags.hg.sourceforge.net/hgweb/mcmc-jags/mcmc-jags/file/15af65a4be29/src/modules/bugs/distributions/DBetaBin.cc

--

-- 
Joan Maspons
CREAF (Centre de Recerca Ecològica i Aplicacions Forestals)
Universitat Autònoma de Barcelona, 08193 Bellaterra (Barcelona), Catalonia
Tel +34 93 581 2915            j.maspons <at> creaf.uab.cat
http://www.creaf.uab.cat
Permalink | Reply | 5 comments |
headers
Wincent | 19 May 07:22
Picon

bug in R version 2.15.0 (2012-03-30)?

The returned text by license() says,

This can be displayed by RShowDoc("COPYING.LIB"),
or obtained at the URI given.

However,
> RShowDoc("COPYING.LIB")
Error in RShowDoc("COPYING.LIB") : document not found

Also, is URI a typo of URL?

--

-- 
Wincent Ronggui HUANG
Sociology Department of Fudan University
PhD of City University of Hong Kong
http://homepage.fudan.edu.cn/rghuang/cv/
Permalink | Reply | 2 comments |
headers
Daniel Fuka | 18 May 17:11
Picon
Favicon

Distributing Executables.

Sorry for this intrusion, but I am confused by two statements that
appear to conflict at some level in Writing R Extensions, and wanted
to make sure I understand the answer to:
Can we distribute a portable executable compiled from source by CRAN in CRAN?

The following section of Writing R Extensions appears to not be
addressing this issue, as in this case we are discussing portable CRAN
compiled binaries, and not binaries that are submitted to CRAN:
"A source package if possible should not contain binary executable
files: they are not portable, and a security risk if they are of the
appropriate architecture. R CMD check will warn about them unless they
are listed (one filepath per line) in a file BinaryFiles at the top
level of the package. Note that CRAN will no longer accept submissions
containing binary files even if they are listed."

The following section seems to indicate special cases in which
packages can create binary files:
"In very special cases packages may create binary files other than the
shared objects/DLLs in the src directory. Such files will not be
installed in multi-arch setting since R CMD INSTALL --libs-only is
used to merge multiple architectures and it only copies shared
objects/DLLs. If a package wants to install other binaries (for
example executable programs), it should to provide an R script
src/install.libs.R which will be run as part of the installation in
the src build directory instead of copying the shared objects/DLLs."

Once again, sorry for my confusion on this point. I just have what I
might consider a special case where it would be very handy to
distribute a cran compiled executable.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Uwe Ligges | 18 May 09:57
Picon
Favicon

Re: Cannot Install Custom Package On Windows7 64-bit


On 18.05.2012 08:55, Steve Pederson wrote:
> Hi,
>
>
>
> After uninstalling Rtools 2.14.0, I have installed the latest version of
> Rtools 2.15.0 which gives the two folders
>
> C:\Rtools\bin
>
> C:\Rtools\gcc-4.6.3
>
>
>
> R is installed in the directory
>
> C:\R\R-2.15.0
>
>
>
> I have set the Environment Variable
>
> PATH=c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\R\R-2.15.0\bin;<others>
>
>
>
> I am trying to install a custom package (BMEA_0.2.1) which is exactly as
> written&  built successfully on R-2.14.0
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steve Pederson | 18 May 08:55
Picon
Picon
Favicon

Cannot Install Custom Package On Windows7 64-bit

Hi,

After uninstalling Rtools 2.14.0, I have installed the latest version of
Rtools 2.15.0 which gives the two folders

C:\Rtools\bin

C:\Rtools\gcc-4.6.3

R is installed in the directory

C:\R\R-2.15.0

I have set the Environment Variable

PATH=c:\Rtools\bin;c:\Rtools\gcc-4.6.3\bin;c:\R\R-2.15.0\bin;<others>

I am trying to install a custom package (BMEA_0.2.1) which is exactly as
written & built successfully on R-2.14.0

When I use R CMD INSTALL BMEA_0.2.1.tar.gz, I get the following output

* installing to library 'C:/R/R-2.15.0/library'

* installing *source* package 'BMEA' ...

** libs

cygwin warning:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Whit Armstrong | 17 May 16:10
Picon

test suites for packages

Can anyone share some opinions on test suites for R packages?

I'm looking at testthat and RUnit. Does anyone have strong opinions on
either of those.

Any additional packages I should consider?

Thanks,
Whit
Permalink | Reply | 6 comments |
headers
Kasper Daniel Hansen | 17 May 14:52
Picon

r-devel fails tests for parallel

I have been building R-devel daily for years.  In the last week or so,
R-devel has failed make check with the error in
  tests/Examples/parallel-Ex.R

The specific error is
> pkgname <- "parallel"
> source(file.path(R.home("share"), "R", "examples-header.R"))
> options(warn = 1)
> library('parallel')
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object
'/hpscc/usr/local/gcc-4.1.2/build/R/R-devel-build/library/parallel/libs/parallel.so':
  /hpscc/usr/local/gcc-4.1.2/build/R/R-devel-build/library/parallel/libs/parallel.so:
undefined symbol: CPU_COUNT
Error: package/namespace load failed for ‘parallel’
Execution halted

I am building on Red Hat Enterprise Linux version 4, using
# gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The specifics of the distro is
# cat /proc/version
Linux version 2.6.18-274.12.1.el5
(mockbuild <at> x86-001.build.bos.redhat.com) (gcc version 4.1.2 20080704
(Red Hat 4.1.2-51)) #1 SMP Tue Nov 8 21:37:35 EST 2011
(Continue reading)

Permalink | Reply | 6 comments |
headers
Terry Therneau | 17 May 14:27
Favicon

Re: Evaluation without the parent frame

Duncan,
   I agree completely with "don't use attach"; if I could get all the 
users of the survival package to agree as well the problem in question 
would go away :-)  I'm thinking about ways to add more effective error 
surveillance.
   Your suggestion was not horribly complex and I'll look into it 
further.  My first foray failed because what I want (I think) is the 
environment that they had when the first ">" came up.  I tried baseenv 
in a spot, but then my code couldn't find the model.frame function.

Terry T.

On 05/17/2012 05:00 AM, Duncan wrote:
> On 12-05-16 4:59 PM, Terry Therneau wrote:
>> >  I've been tracking down a survival problem from R-help today.  A short
>> >  version of the primary issue is reconstructed by the following simple
>> >  example:
>> >
>> >  library(survival)
>> >  attach(lung)
>> >  fit<- coxph(Surv(time, status) ~ log(age))
>> >  predict(fit, newdata=data.frame(abe=45))
>> >
>> >  Note the typo in the last line of "abe" instead of "age".  Instead of an
>> >  error message, this returns predictions for all the subjects since
>> >  model.frame matches "age" by searching more widely.   I'd prefer the error.
>> >  I suspect this is hard -- I'd like it to not see the attached lung data
>> >  set, but still be able to find the log function.
>> >  Is there a not-horribly-complex solution?
> The best solution is to not use attach(), use data=lung in the fit.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane