On 03/12/2013 02:15 PM, Simon Urbanek wrote:
On Mar 12, 2013, at 4:56 PM, Hervé Pagès wrote:
On 03/12/2013 12:53 PM, Simon Urbanek wrote:
On Mar 12, 2013, at 3:35 PM, Hervé Pagès wrote:
On 03/12/2013 11:56 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 2:48 PM, Hervé Pagès wrote:
On
On 03/12/2013 02:14 PM, Dirk Eddelbuettel wrote:
On 12 March 2013 at 13:56, Hervé Pagès wrote:
| The reason I'm interested in clarifying this is that we are facing
| a similar situation with other libraries (e.g. the BOOST library)
| used by some Bioconductor packages. Right now, each Bioconduct
On 03/12/2013 09:55 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 12:30 PM, Kevin Horan wrote:
Thanks for your input. To clarify, I don't need to use any part of GSL in
my R code, nor do I wish to make any part of it accessible to users of eiR. I
need it to compile other C/C++ code (LSH
Hi R users,
I'm a quite extensive user of the heatmap() function, and as many others
i'm frequently frustrated by its fixed square width / height ratio. Here is
a typical example :
dev.new()
heatmap(matrix(rnorm(1200), nrow=10))
I have a non square matrix to plot with heatmap, as there
I've been trying to set up a mocking framework to use in testing, in
conjunction with testthat. I come from a java background.
What I've settled on is calling methods(class=klass), adding a "mock" to
the name and assigning a function that returns null to the new name in the
base environment. I'v
Thanks for your input. To clarify, I don't need to use any part of
GSL in my R code, nor do I wish to make any part of it accessible to
users of eiR. I need it to compile other C/C++ code (LSH KIT), which I
did not write, that will itself be used in eiR.
My goal is allow the user to in
On Mar 12, 2013, at 4:56 PM, Hervé Pagès wrote:
>
>
> On 03/12/2013 12:53 PM, Simon Urbanek wrote:
>>
>> On Mar 12, 2013, at 3:35 PM, Hervé Pagès wrote:
>>
>>>
>>>
>>> On 03/12/2013 11:56 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 2:48 PM, Hervé Pagès wrote:
> On 03/1
On 12 March 2013 at 13:56, Hervé Pagès wrote:
| The reason I'm interested in clarifying this is that we are facing
| a similar situation with other libraries (e.g. the BOOST library)
| used by some Bioconductor packages. Right now, each Bioconductor
| package includes its own version of the BOOST
On 03/12/2013 12:53 PM, Simon Urbanek wrote:
On Mar 12, 2013, at 3:35 PM, Hervé Pagès wrote:
On 03/12/2013 11:56 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 2:48 PM, Hervé Pagès wrote:
On 03/12/2013 11:09 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 2:01 PM, Hervé Pagès wrote:
Hi,
Thanks for the report. Fixed in r62220 on trunk, r62221 on
R-3-0-branch, and r6 on R-2-15-branch.
Best,
luke
On Tue, 12 Mar 2013, Radford Neal wrote:
Several bugs are present in R-2.15.3 and R-alpha due to
naive copying of list elements.
The bug below is due to naive copying in subset.c
On Mar 12, 2013, at 3:35 PM, Hervé Pagès wrote:
>
>
> On 03/12/2013 11:56 AM, Simon Urbanek wrote:
>>
>> On Mar 12, 2013, at 2:48 PM, Hervé Pagès wrote:
>>
>>> On 03/12/2013 11:09 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 2:01 PM, Hervé Pagès wrote:
> Hi,
>
>
Hi,
FWIW, seems to be a bug that a subrange of a list can not be named/properly
referenced counted and therefore does not force a deepcopy to be made when a is
later changed. The following works exactly as expected and the only difference
is that it creates "b" from the entire list "a" before
On 03/12/2013 11:56 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 2:48 PM, Hervé Pagès wrote:
On 03/12/2013 11:09 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 2:01 PM, Hervé Pagès wrote:
Hi,
On 03/12/2013 09:55 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 12:30 PM, Kevin Horan wrote:
Circa 80 CRAN and core-R packages have duplicate export entries in their
NAMESPACE files. E.g.,
bit 1.1.9 : c("as.bit", "as.bitwhich", "as.which", "physical", "virtual")
forecast 4.1 : "forecast.lm"
graphics 2.15.3 : "barplot"
mcmc 0.9.1 : "morph"
RCurl 1.95.3 : "curlOptions"
util
On Mar 12, 2013, at 2:48 PM, Hervé Pagès wrote:
> On 03/12/2013 11:09 AM, Simon Urbanek wrote:
>>
>> On Mar 12, 2013, at 2:01 PM, Hervé Pagès wrote:
>>
>>> Hi,
>>>
>>> On 03/12/2013 09:55 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 12:30 PM, Kevin Horan wrote:
>
>
On 03/12/2013 11:09 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 2:01 PM, Hervé Pagès wrote:
Hi,
On 03/12/2013 09:55 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 12:30 PM, Kevin Horan wrote:
Thanks for your input. To clarify, I don't need to use any part of GSL in
my R code, nor do
Whereas
> a <- list(c(1,2),c(3,4),c(5,6))
> b <<- a[2:3]
> a[[2]][2] <- 9
> b
[[1]]
[1] 3 4
[[2]]
[1] 5 6
>
Examples such as this leave me in a cold sweat - where did I miss the
documentation describing
Radford's case? Can anyone point to the documentation that describes Radford's
outcome?
On 12 March 2013 at 11:01, Hervé Pagès wrote:
| Anyway, to answer Kevin's original question:
|
|how do I know where the GSL library and header files, packaged
|in GSLR, would live so I can point the compiler at them?
|
| Use the LinkingTo field.
Nope. Only covers the case of include fil
On Mar 12, 2013, at 2:01 PM, Hervé Pagès wrote:
> Hi,
>
> On 03/12/2013 09:55 AM, Simon Urbanek wrote:
>>
>> On Mar 12, 2013, at 12:30 PM, Kevin Horan wrote:
>>
>>>
>>>Thanks for your input. To clarify, I don't need to use any part of GSL
>>> in my R code, nor do I wish to make any part
Hi,
On 03/12/2013 09:55 AM, Simon Urbanek wrote:
On Mar 12, 2013, at 12:30 PM, Kevin Horan wrote:
Thanks for your input. To clarify, I don't need to use any part of GSL in
my R code, nor do I wish to make any part of it accessible to users of eiR. I
need it to compile other C/C++ code
On Mar 12, 2013, at 3:59 AM, Radford Neal wrote:
> Several bugs are present in R-2.15.3 and R-alpha due to
> naive copying of list elements.
>
> The bug below is due to naive copying in subset.c (with
> similar bugs for matrices and arrays):
>
> a<-list(c(1,2),c(3,4),c(5,6))
> b<-a[2:3]
> a[[2]
On Mar 12, 2013, at 12:30 PM, Kevin Horan wrote:
>
>Thanks for your input. To clarify, I don't need to use any part of GSL in
> my R code, nor do I wish to make any part of it accessible to users of eiR. I
> need it to compile other C/C++ code (LSH KIT), which I did not write, that
> will
On 12 March 2013 at 08:26, Simon Urbanek wrote:
| Kevin,
|
| On Mar 11, 2013, at 5:20 PM, Kevin Horan wrote:
|
| >
| > I am developing an R package, eiR, which depends on another C library, GNU
scientific library (GSL). In order to make life easier for the user, it would
be nice to not have
It is possible to list binaries in BinaryFiles and thereby excluded
them from R CMD check (although they are disallowed by CRAN).
I am interested in the same functionality, but for object files.
Background: in Rgraphviz, we (I) include pre-compiled object files for
use on Windows, because generati
Kevin,
On Mar 11, 2013, at 5:20 PM, Kevin Horan wrote:
>
> I am developing an R package, eiR, which depends on another C library, GNU
> scientific library (GSL). In order to make life easier for the user, it would
> be nice to not have this as an external dependency, thus I would like to wrap
Several bugs are present in R-2.15.3 and R-alpha due to
naive copying of list elements.
The bug below is due to naive copying in subset.c (with
similar bugs for matrices and arrays):
a<-list(c(1,2),c(3,4),c(5,6))
b<-a[2:3]
a[[2]][2]<-9
print(b[[1]][2])
Naive copying in mapply.c leads to the foll
I am developing an R package, eiR, which depends on another C library,
GNU scientific library (GSL). In order to make life easier for the user,
it would be nice to not have this as an external dependency, thus I
would like to wrap this library in another R package, say GSLR for
example. Thus
27 matches
Mail list logo
