Re: [Rd] Trouble installing Rcpp on AIX - missing "execinfo.h"
Dirk and Edward,
Thanks for the help.
I found for AIX that "execinfo.h" basically did nothing that I could tell. What
I ended up doing was replacing the line in api.cpp "#include " with
the following from gnulib:
int backtrace (void **buffer, int size)
{
(void) buffer;
(void) size;
return 0;
}
char **backtrace_symbols (void *const *buffer, int size)
{
(void) buffer;
(void) size;
return 0;
}
void backtrace_symbols_fd (void *const *buffer, int size, int fd)
{
(void) buffer;
(void) size;
(void) fd;
}
So I've probably lost some functionality over other popular Unix systems, but
the few examples that I ran from the Rcpp help pages, and for other packages
that depend on Rcpp, seemed to indicate that what got built essentially works
fine.
Up till now, at my work we've been moving data back and forth between AIX (data
generation) and Windows (R analysis). I'm no fan of AIX, but we needed R on AIX
so we can avoid all the data movement and be more productive.
I am going to have to learn more about Rcpp. This was really my first encounter
with it - my co-worker depends on it so I was trying to build it on AIX for her.
I want to thank you both very much for the tips and help. If I can be of
service to help with testing on AIX, please feel free to reach out to me.
Building the base R system for AIX 7.1 was no small feat for me - I spent days
back and forth between the IBM XL and GNU compilers, trying to find the flags
that would work. The R Admin guide got me 80% of the way there, but I had to
patch a system header file, etc. Once that was done, building the recommended
packages went ok for the most part, but building Matrix gave lots of warnings
but seems to work. AIX is no friend to non-IBM softwares.
I will subscribe to the rcpp-devel list, and probably buy the book.
Mike Beddo
-Original Message-
From: Dirk Eddelbuettel [mailto:e...@debian.org]
Sent: Friday, October 31, 2014 8:32 PM
To: Mike Beddo
Cc: r-devel@r-project.org
Subject: Re: [Rd] Trouble installing Rcpp on AIX - missing "execinfo.h"
On 30 October 2014 at 04:13, Mike Beddo wrote:
| Greetings,
|
| When I try "install.packages('Rcpp')" it fails when compiling api.cpp (line
39). This is Rcpp 0.11.3. I searched my filesystem, and indeed I do not have
execinfo.h anywhere. After some effort, I got R build on AIX. Now I am trying
to build the packages I need. Rcpp is crucial.
|
| I first build R with the native IBM XL compilers, and Rcpp wouldn't build.
That was because it wasn't a "GOOD COMPILER" (there's a directive in the Rcpp
code that checks for various types of compilers). So I switched to building R
with gcc/gfortran/g++ 4.8 and got past that point, but now blocked by the
absence of "execinfo.h" header file.
|
| Any ideas?
I would have replied sooner if you had used the proper list -- which for
matters pertaining to Rcpp is the rcpp-devel list (and note that you need
subscribe first in order to post).
For systems we do not have access to -- like Solaris, Aix, or equally antique
and rarified Unix systems -- we do rely on those having access to run tests.
Worst case we can #ifdef some features away so that you can build with a
possibly sightly reduced feature set. But you, or someone else on Aix, needs
to drive this as we can't.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trouble installing Rcpp on AIX - missing "execinfo.h"
On 30 October 2014 at 04:13, Mike Beddo wrote:
| Greetings,
|
| When I try "install.packages('Rcpp')" it fails when compiling api.cpp (line
39). This is Rcpp 0.11.3. I searched my filesystem, and indeed I do not have
execinfo.h anywhere. After some effort, I got R build on AIX. Now I am trying
to build the packages I need. Rcpp is crucial.
|
| I first build R with the native IBM XL compilers, and Rcpp wouldn't build.
That was because it wasn't a "GOOD COMPILER" (there's a directive in the Rcpp
code that checks for various types of compilers). So I switched to building R
with gcc/gfortran/g++ 4.8 and got past that point, but now blocked by the
absence of "execinfo.h" header file.
|
| Any ideas?
I would have replied sooner if you had used the proper list -- which for
matters pertaining to Rcpp is the rcpp-devel list (and note that you need
subscribe first in order to post).
For systems we do not have access to -- like Solaris, Aix, or equally antique
and rarified Unix systems -- we do rely on those having access to run tests.
Worst case we can #ifdef some features away so that you can build with a
possibly sightly reduced feature set. But you, or someone else on Aix, needs
to drive this as we can't.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Options that are local to the package that sets them
On Fri, Oct 31, 2014 at 9:26 PM, Martin Morgan wrote:
[...]
> You'll need pkgA to be able to know that pkgB1's invokation is to use
> pkgB1's parameters, so coupling state (parameters) with function, i.e., a
> class with methods. So a solution is to use an S4 or reference class and
> generator to encapsulate state and dispatch to appropriate functions, E.g.,
>
> .Plotter <- setRefClass("Plotter",
> fields=list(palette="character"),
> methods=list(
> update(palette) {
> .self$palette <- palette
> },
> plot=function(...) {
> graphics::plot(..., col=.self$palette)
> }))
>
> APlotter <- function(palette=c("red", "green", "blue"))
> .Plotter(palette=palette)
>
> PkgB1, 2 would then
>
> plt = APlotter()
> plt$plot(mpg ~ disp, mtcars)
> plt$update(c("blue", "green"))
> plt$plot(mpg ~ disp, mtcars)
>
> or
>
> .S4Plotter <- setClass("S4Plotter", representation(palette="character")
> S4Plotter <- function(palette=c("red", "blue", "green"))
> s4plot <- function(x, ...) graphics::plot(..., col=x@palette))
>
> (make s4plot a generic with method for class S4Plotter to enforce type).
>
> Seems like this interface could be generated automatically in .onLoad() of
> pkgA, especially if adopting a naming convention of some sort.
Yes, I think this works, and all three of us came to essentially the
same solution.
Unfortunately, this solution also requires putting the whole pkgA API
inside such a class, otherwise the pkgA functions will not find the
right settings.
Thanks again!
Gabor
[...]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Options that are local to the package that sets them
On Fri, Oct 31, 2014 at 9:20 PM, Gabor Grothendieck wrote: [...] > Isn't your problem really just that you want multiple sets of > settings? That's what settings provides. Almost. Multiple sets of settings, set up by the same package. So essentially I want pkgA to use different settings when called from different packages. E.g. imagine that my package igraph has an option that sets a color plot plotting. Another package, qgraph sets this setting to something, say "red". Now another package xgraph wants to set it to "green". What I want is to use "red" when plotting through qgraph, and to use "green" when plotting from xgraph. igraph provides the API for setting this option, so if I just use 'settings' (or a similar technique) in igraph, then xgraph's setting will overwrite qgraph's setting. > pkgA would provide a class whose instances are created by the clients. > Assuming you wrap this in a function create: > > inst1 <- create(a = 1, b = 2) > > where create sets up a settings object and does anything else > returning the handle inst1. > > When you want to do something you would pass the instance to the > function or method that actually carries it out. This could be done > with any OO system in R without settings but if you are looking for an > options type interface which I thought you were then you might be able > to leverage that package. You are right, this should work. I would like to avoid passing the settings object to each and every igraph function, though. (Would need to update 500+ functions.) But that does not seem to be possible, unless I start messing with the call stack. G. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Options that are local to the package that sets them
On 10/31/2014 05:55 PM, Gábor Csárdi wrote:
On Fri, Oct 31, 2014 at 8:16 PM, William Dunlap wrote:
You can put the following 3 objects, an environment and 2 functions
that access it, in any package that need some package-specific
storage (say your pkgB1 and pkgB2).
.pkgLocalStorage <- new.env(parent = emptyenv())
assignInPkgLocalStorage <- function(name, object) {
.pkgLocalStorage[[name]] <- object
}
getFromPkgLocalStorage <- function(name, object) {
.pkgLocalStorage[[name]]
}
Leave the environment private and export the functions. Then a user can
use them as
pkgB1::assignInPkgLocalStorage("myPallete", makeAPallete(1,2,3))
pkgB2::assignInPkgLocalStorage("myPallete", makeAPallete(5,6,7))
pkgB1::getFromPkgLocalStorage("myPallete") # get the 1,2,3 pallete
I am trying to avoid requiring pkgBn to do this kind of magic. I just
want it to call function(s) from pkgA. But maybe something like this
would work. In pkgBn:
my_palettes <- pkgA::palette_factory()
and my_palettes is a function or an environment that has the API
functions to modify my_palettes itself (via closure if it is a
function), e.g.
my_palettes$add_palette(...)
my_palettes$get_palette(...)
or if it is a function, then
my_palettes(add(...), ...)
my_palettes(get(...), ...)
etc.
This would work, right? I'll try it in a minute.
You'll need pkgA to be able to know that pkgB1's invokation is to use pkgB1's
parameters, so coupling state (parameters) with function, i.e., a class with
methods. So a solution is to use an S4 or reference class and generator to
encapsulate state and dispatch to appropriate functions, E.g.,
.Plotter <- setRefClass("Plotter",
fields=list(palette="character"),
methods=list(
update(palette) {
.self$palette <- palette
},
plot=function(...) {
graphics::plot(..., col=.self$palette)
}))
APlotter <- function(palette=c("red", "green", "blue"))
.Plotter(palette=palette)
PkgB1, 2 would then
plt = APlotter()
plt$plot(mpg ~ disp, mtcars)
plt$update(c("blue", "green"))
plt$plot(mpg ~ disp, mtcars)
or
.S4Plotter <- setClass("S4Plotter", representation(palette="character")
S4Plotter <- function(palette=c("red", "blue", "green"))
s4plot <- function(x, ...) graphics::plot(..., col=x@palette))
(make s4plot a generic with method for class S4Plotter to enforce type).
Seems like this interface could be generated automatically in .onLoad() of pkgA,
especially if adopting a naming convention of some sort.
Martin
Gabor
If only one of pkgB1 and pkgB2 is loaded you can leave off the pkgBn::.
A package writer can always leave off the pkgBn:: as well.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Oct 31, 2014 at 4:34 PM, Gábor Csárdi wrote:
Dear All,
I am trying to do the following, and could use some hints.
Suppose I have a package called pkgA. pkgA exposes an API that
includes setting some options, e.g. pkgA works with color palettes,
and the user of the package can define new palettes. pkgA provides an
API to manipulate these palettes, including defining them.
pkgA is intended to be used in other packages, e.g. in pkgB1 and
pkgB2. Now suppose pkgB1 and pkgB2 both set new palettes using pkgA.
They might set palettes with the same name, of course, they do not
know about each other.
My question is, is there a straightforward way to implement pkgA's
API, such that pkgB1 and pkgB2 do not interfere? In other words, if
pkgB1 and pkgB2 both define a palette 'foo', but they define it
differently, each should see her own version of it.
I guess this requires that I put something (a function?) in both
pkgB1's and pkgB2's package namespace. As I see it, this can only
happen when pkgA's API is called from pkgB1 (and pkgB2).
So at this time I could just walk up the call tree and put the palette
definition in the first environment that is not pkgA's. This looks
somewhat messy, and I am probably missing some caveats.
Is there a better way? I have a feeling that this is already supported
somehow, I just can't find out how.
Thanks, Best Regards,
Gabor
__
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
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Options that are local to the package that sets them
On Fri, Oct 31, 2014 at 8:43 PM, Gábor Csárdi wrote: > On Fri, Oct 31, 2014 at 8:10 PM, Gabor Grothendieck > wrote: > [...] >>> Is there a better way? I have a feeling that this is already supported >>> somehow, I just can't find out how. >>> >> >> Try the settings package. > > I could, but I don't see how it would solve my problem. > https://github.com/markvanderloo/settings/issues/1 Isn't your problem really just that you want multiple sets of settings? That's what settings provides. pkgA would provide a class whose instances are created by the clients. Assuming you wrap this in a function create: inst1 <- create(a = 1, b = 2) where create sets up a settings object and does anything else returning the handle inst1. When you want to do something you would pass the instance to the function or method that actually carries it out. This could be done with any OO system in R without settings but if you are looking for an options type interface which I thought you were then you might be able to leverage that package. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trouble installing Rcpp on AIX - missing "execinfo.h"
Mike,
Perhaps this will help: http://cygwin.com/ml/cygwin/2012-04/msg00346.html
Regards,
Ed Davignon
On Thu, Oct 30, 2014 at 12:13 AM, Mike Beddo
wrote:
> Greetings,
>
> When I try "install.packages('Rcpp')" it fails when compiling api.cpp
> (line 39). This is Rcpp 0.11.3. I searched my filesystem, and indeed I do
> not have execinfo.h anywhere. After some effort, I got R build on AIX. Now
> I am trying to build the packages I need. Rcpp is crucial.
>
> I first build R with the native IBM XL compilers, and Rcpp wouldn't build.
> That was because it wasn't a "GOOD COMPILER" (there's a directive in the
> Rcpp code that checks for various types of compilers). So I switched to
> building R with gcc/gfortran/g++ 4.8 and got past that point, but now
> blocked by the absence of "execinfo.h" header file.
>
> Any ideas?
>
> Thanks,
>
> Mike
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Appropriately Crediting Use of R Source Code in Package
I'm developing packages that in some places use code that started off as a direct copy-paste from the R sources (this is C code). The finished code is fairly different from what I started with, but clearly uses similar algorithms / tricks as the original code, and some lines here and there are still verbatim copies. What is the correct way to credit the R developers in DESCRIPTION? As copyright holders? As contributors / authors (though it almost seems presumptuous for me to associate them with my crappy package)? If so, should I use "R Core Team" as seems to be the standard in base R packages for authors? I've looked in Writing R extensions, the 6/2012 R Journal article, and other places and can't quite find an answer for my use case (I may be obtuse). [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Options that are local to the package that sets them
On Fri, Oct 31, 2014 at 8:16 PM, William Dunlap wrote:
> You can put the following 3 objects, an environment and 2 functions
> that access it, in any package that need some package-specific
> storage (say your pkgB1 and pkgB2).
>.pkgLocalStorage <- new.env(parent = emptyenv())
>assignInPkgLocalStorage <- function(name, object) {
>.pkgLocalStorage[[name]] <- object
>}
>getFromPkgLocalStorage <- function(name, object) {
>.pkgLocalStorage[[name]]
>}
> Leave the environment private and export the functions. Then a user can
> use them as
>pkgB1::assignInPkgLocalStorage("myPallete", makeAPallete(1,2,3))
>pkgB2::assignInPkgLocalStorage("myPallete", makeAPallete(5,6,7))
>pkgB1::getFromPkgLocalStorage("myPallete") # get the 1,2,3 pallete
I am trying to avoid requiring pkgBn to do this kind of magic. I just
want it to call function(s) from pkgA. But maybe something like this
would work. In pkgBn:
my_palettes <- pkgA::palette_factory()
and my_palettes is a function or an environment that has the API
functions to modify my_palettes itself (via closure if it is a
function), e.g.
my_palettes$add_palette(...)
my_palettes$get_palette(...)
or if it is a function, then
my_palettes(add(...), ...)
my_palettes(get(...), ...)
etc.
This would work, right? I'll try it in a minute.
Gabor
> If only one of pkgB1 and pkgB2 is loaded you can leave off the pkgBn::.
>
> A package writer can always leave off the pkgBn:: as well.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Fri, Oct 31, 2014 at 4:34 PM, Gábor Csárdi wrote:
>> Dear All,
>>
>> I am trying to do the following, and could use some hints.
>>
>> Suppose I have a package called pkgA. pkgA exposes an API that
>> includes setting some options, e.g. pkgA works with color palettes,
>> and the user of the package can define new palettes. pkgA provides an
>> API to manipulate these palettes, including defining them.
>>
>> pkgA is intended to be used in other packages, e.g. in pkgB1 and
>> pkgB2. Now suppose pkgB1 and pkgB2 both set new palettes using pkgA.
>> They might set palettes with the same name, of course, they do not
>> know about each other.
>>
>> My question is, is there a straightforward way to implement pkgA's
>> API, such that pkgB1 and pkgB2 do not interfere? In other words, if
>> pkgB1 and pkgB2 both define a palette 'foo', but they define it
>> differently, each should see her own version of it.
>>
>> I guess this requires that I put something (a function?) in both
>> pkgB1's and pkgB2's package namespace. As I see it, this can only
>> happen when pkgA's API is called from pkgB1 (and pkgB2).
>>
>> So at this time I could just walk up the call tree and put the palette
>> definition in the first environment that is not pkgA's. This looks
>> somewhat messy, and I am probably missing some caveats.
>>
>> Is there a better way? I have a feeling that this is already supported
>> somehow, I just can't find out how.
>>
>> Thanks, Best Regards,
>> Gabor
>>
>> __
>> 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] Options that are local to the package that sets them
On Fri, Oct 31, 2014 at 8:10 PM, Gabor Grothendieck wrote: [...] >> Is there a better way? I have a feeling that this is already supported >> somehow, I just can't find out how. >> > > Try the settings package. I could, but I don't see how it would solve my problem. https://github.com/markvanderloo/settings/issues/1 Gabor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Options that are local to the package that sets them
You can put the following 3 objects, an environment and 2 functions
that access it, in any package that need some package-specific
storage (say your pkgB1 and pkgB2).
.pkgLocalStorage <- new.env(parent = emptyenv())
assignInPkgLocalStorage <- function(name, object) {
.pkgLocalStorage[[name]] <- object
}
getFromPkgLocalStorage <- function(name, object) {
.pkgLocalStorage[[name]]
}
Leave the environment private and export the functions. Then a user can
use them as
pkgB1::assignInPkgLocalStorage("myPallete", makeAPallete(1,2,3))
pkgB2::assignInPkgLocalStorage("myPallete", makeAPallete(5,6,7))
pkgB1::getFromPkgLocalStorage("myPallete") # get the 1,2,3 pallete
If only one of pkgB1 and pkgB2 is loaded you can leave off the pkgBn::.
A package writer can always leave off the pkgBn:: as well.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Oct 31, 2014 at 4:34 PM, Gábor Csárdi wrote:
> Dear All,
>
> I am trying to do the following, and could use some hints.
>
> Suppose I have a package called pkgA. pkgA exposes an API that
> includes setting some options, e.g. pkgA works with color palettes,
> and the user of the package can define new palettes. pkgA provides an
> API to manipulate these palettes, including defining them.
>
> pkgA is intended to be used in other packages, e.g. in pkgB1 and
> pkgB2. Now suppose pkgB1 and pkgB2 both set new palettes using pkgA.
> They might set palettes with the same name, of course, they do not
> know about each other.
>
> My question is, is there a straightforward way to implement pkgA's
> API, such that pkgB1 and pkgB2 do not interfere? In other words, if
> pkgB1 and pkgB2 both define a palette 'foo', but they define it
> differently, each should see her own version of it.
>
> I guess this requires that I put something (a function?) in both
> pkgB1's and pkgB2's package namespace. As I see it, this can only
> happen when pkgA's API is called from pkgB1 (and pkgB2).
>
> So at this time I could just walk up the call tree and put the palette
> definition in the first environment that is not pkgA's. This looks
> somewhat messy, and I am probably missing some caveats.
>
> Is there a better way? I have a feeling that this is already supported
> somehow, I just can't find out how.
>
> Thanks, Best Regards,
> Gabor
>
> __
> 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] Options that are local to the package that sets them
On Fri, Oct 31, 2014 at 7:34 PM, Gábor Csárdi wrote: > Dear All, > > I am trying to do the following, and could use some hints. > > Suppose I have a package called pkgA. pkgA exposes an API that > includes setting some options, e.g. pkgA works with color palettes, > and the user of the package can define new palettes. pkgA provides an > API to manipulate these palettes, including defining them. > > pkgA is intended to be used in other packages, e.g. in pkgB1 and > pkgB2. Now suppose pkgB1 and pkgB2 both set new palettes using pkgA. > They might set palettes with the same name, of course, they do not > know about each other. > > My question is, is there a straightforward way to implement pkgA's > API, such that pkgB1 and pkgB2 do not interfere? In other words, if > pkgB1 and pkgB2 both define a palette 'foo', but they define it > differently, each should see her own version of it. > > I guess this requires that I put something (a function?) in both > pkgB1's and pkgB2's package namespace. As I see it, this can only > happen when pkgA's API is called from pkgB1 (and pkgB2). > > So at this time I could just walk up the call tree and put the palette > definition in the first environment that is not pkgA's. This looks > somewhat messy, and I am probably missing some caveats. > > Is there a better way? I have a feeling that this is already supported > somehow, I just can't find out how. > Try the settings package. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Options that are local to the package that sets them
Dear All, I am trying to do the following, and could use some hints. Suppose I have a package called pkgA. pkgA exposes an API that includes setting some options, e.g. pkgA works with color palettes, and the user of the package can define new palettes. pkgA provides an API to manipulate these palettes, including defining them. pkgA is intended to be used in other packages, e.g. in pkgB1 and pkgB2. Now suppose pkgB1 and pkgB2 both set new palettes using pkgA. They might set palettes with the same name, of course, they do not know about each other. My question is, is there a straightforward way to implement pkgA's API, such that pkgB1 and pkgB2 do not interfere? In other words, if pkgB1 and pkgB2 both define a palette 'foo', but they define it differently, each should see her own version of it. I guess this requires that I put something (a function?) in both pkgB1's and pkgB2's package namespace. As I see it, this can only happen when pkgA's API is called from pkgB1 (and pkgB2). So at this time I could just walk up the call tree and put the palette definition in the first environment that is not pkgA's. This looks somewhat messy, and I am probably missing some caveats. Is there a better way? I have a feeling that this is already supported somehow, I just can't find out how. Thanks, Best Regards, Gabor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposed: minor change to error message
On 31/10/2014, 2:22 PM, Dan Tenenbaum wrote: > When checking a package (call it "A") that has "Enhances: B" in DESCRIPTION, > I get the message: > > Package which this enhances but not available for checking: ‘B’ > > Can this be changed to: > > Package which enhances this but not available for checking: ‘B’ > > ? > > Because really, B is not enhanced by A, B does not need A at all. > > (Actually, for the same reason, Enhances should be EnhancedBy, but I am not > suggesting changing that because I realize that is non-trivial.) I think you've got it wrong. Saying Enhances: B is explicitly a claim that your package A does enhance B. Read "Writing R Extensions". Not all claims made in packages are true, but that's a different issue. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ScalarLogical and setAttrib
Is it expected that attributes set on a LGLSXP created by
ScalarLogical will apply to all future objects created by
ScalarLogical as well? For example: the 'test1' function below returns
FALSE and 'test2' returns FALSE with an attribute:
library(inline)
test1 <- cfunction(body = 'return ScalarLogical(0);')
test2 <- cfunction(body = '
SEXP success = PROTECT(ScalarLogical(0));
setAttrib(success, install("foo"), mkString("bar"));
UNPROTECT(1);
return success;
')
However after running test2(), then test1() will also return the attribute:
> test1()
[1] FALSE
> test2()
[1] FALSE
attr(,"foo")
[1] "bar"
> test1()
[1] FALSE
attr(,"foo")
[1] "bar"
It seems like ScalarLogical returns a singleton object, which is not
the case for ScalarInteger or ScalarReal. I am currently working
around this using duplicate(ScalarLogical(0)), but was quite surprised
by this behavior of ScalarLogical.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proposed: minor change to error message
When checking a package (call it "A") that has "Enhances: B" in DESCRIPTION, I get the message: Package which this enhances but not available for checking: ‘B’ Can this be changed to: Package which enhances this but not available for checking: ‘B’ ? Because really, B is not enhanced by A, B does not need A at all. (Actually, for the same reason, Enhances should be EnhancedBy, but I am not suggesting changing that because I realize that is non-trivial.) Thanks, Dan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'library' or 'require' call not declared from: 'rgl'
On Thu, 2014-10-30 at 17:18 -0400, Michael Friendly wrote:
> On 10/30/2014 4:19 PM, Simon Urbanek wrote:
> > Did you intend rgl to be optional? If so, then you should use
> Suggests: instead. When you use Imports: it will load rgl
> automatically so require() does't make sense (since it will be always
> TRUE).
> >
> I always had it as Suggests: rgl before. But R-devel now gave be all
> those "no visible global function definition for ..."
> messages.
>
> Achim suggested using explicitly rgl:: everywhere. That's quite ugly,
> but seems to work.
I think you do want "Depends" rather than "Suggests" here. "Suggests" is
for when the other package does not need to be loaded for the user to
use your package, but the other package might be used in an example or
vignette.
In your package, the default method for a generic function that your
package defines calls functions from rgl. To me that means rgl should be
in "Depends", and the required functions from rgl should be imported in
the NAMESPACE file.
Martyn
---
This message and its attachments are strictly confidenti...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
