> Martin Maechler
> on Tue, 8 Dec 2015 15:25:21 +0100 writes:
> John Chambers
> on Mon, 7 Dec 2015 16:05:59 -0800 writes:
>> We do need an explicit method here, I think.
>> The issue is that as() uses methods for the generic function coerce()
but cannot use inhe
In addition to what Charles wrote, you can also use 'local' if you don't
want a function that creates another function.
> f <- local({info <- 10; function(x) x + info})
> f(3)
[1] 13
best,
Mark
Op vr 11 dec. 2015 om 03:27 schreef Charles C. Berry :
> On Thu, 10 Dec 2015, Konrad Rudolph wrote:
Hello all,
I have spent the last week going through the configure/configure.ac
file, basically line-by-line.
I am finding things related to AIX that have not been working well
(i.e., cleanly) for 32-bit builds and are a "root-cause" for 64-bit
builds to finish cleanly.
Trying to keep this sh
I have intstalled R-3.2.2,Rcpp-0.12.2,RInside-0.2.13 on windows. I compiled
the example1 of RInside in the
example directory which create a RInside instance and prints "hello world". The
compiler is intel c++. I included
the RInside source files in the project and fixed the compile and link e
Thanks. I know about `local` (and functions within functions). In
fact, the functions are *already* defined inside their own environment
(same as what `local` does). But unfortunately this doesn’t solve my
problem, since the functions’ parent environment gets changed during
the function’s execution
On Thu, Dec 10, 2015 at 5:49 PM, Konrad Rudolph
wrote:
> I’ve got the following scenario: I need to store information about an
> R function, and retrieve it at a later point. In other programming
> languages I’d implement this using a dictionary with the functions as
> keys. In R, I’d usually use
Eric,
This must now be your third or fourth email on this matter (counting the one
to me directly, and to be clear I much prefer this on list). I'll be brief:
On 11 December 2015 at 20:50, 李琥 wrote:
|
| I have intstalled R-3.2.2,Rcpp-0.12.2,RInside-0.2.13 on windows. I compiled
the example1
On Fri, Dec 11, 2015 at 12:49 AM, Konrad Rudolph
wrote:
>
> On the chance that I’m trying to solve the wrong Y to an X/Y problem,
> the full context to the above problem is explained in [1]. In a
> nutshell, I am hooking a new environment into a function’s parent.env
> chain, by re-assigning the f
@Jeroen, here’s what I’m solving with my hacking the parent
environment chain: I’m essentially re-implementing `base::attach` —
except that I’m attaching objects *locally* in the function instead of
globally. I don’t think this can be done in any way except by
modifying the parent environment chain
On Fri, Dec 11, 2015 at 1:26 PM, Hadley Wickham wrote:
> Why not use your own S3 class?
Yes, I’ll probably do that. Thanks. I honestly don’t know why I hadn’t
thought of that before, since I’m doing the exact same thing in
another context [1].
[1]:
https://github.com/klmr/decorator/blob/2742b39
Somehow, the most obvious fixes are always back-incompatible these days.
The example intrigued me, so I looked into it a bit (should have been doing
something else, but )
You're right that this is the proverbial thin-edge-of-the-wedge.
The problem is in setDataPart(), which will be called w
>From the Bioconductor side of things, the general feeling is that this is a
>step in the right direction and worth the broken packages. Martin Morgan
From: R-devel [r-devel-boun...@r-project.org] on behalf of Martin Maechler
[maech...@stat.math.ethz.ch]
S
12 matches
Mail list logo
