> Gergely Daróczi
> on Thu, 10 Nov 2016 16:48:12 +0100 writes:
> Dear All,
> I'm developing an R application running inside of a Java daemon on
> multiple threads, and interacting with the parent daemon via stdin and
> stdout.
> Everything works perfectly fine exc
On Fri, Nov 11, 2016 at 12:08 PM, Martin Maechler
wrote:
>> Gergely Daróczi
>> on Thu, 10 Nov 2016 16:48:12 +0100 writes:
>
> > Dear All,
> > I'm developing an R application running inside of a Java daemon on
> > multiple threads, and interacting with the parent daemon via
Hi,
I was trying to get a list of S3 method for a given generic, along with the
package in which they are defined, and I came across what looks like an
issue in the data.frame returned in attribute 'info'. The column 'from'
mostly gets the value "registered S3method for ..." except for visible
met
On Fri, Nov 11, 2016 at 12:46 PM, Gergely Daróczi
wrote:
[...]
>> I've changed the above to *print* the gc() result every 1000th
>> iteration, and after 100'000 iterations, there is still no
>> memory increase from the point of view of R itself.
Yes, R does not know about it, it does not manage t
I noticed some problems that cropped in the latest versions of R-devel
(2016-11-08 r71639 in my case) for one of my packages. I _think_ I have
narrowed it down to the changes to what gets byte-compiled by default. The
following example run illustrates the problem I'm having:
compiler::enabl
It looks like the byte compiler is optimizing local() to an
immediately-invoked function, instead of using eval() and substitute(). I
don't know if that's exactly how it's implemented internally, but that's
what it looks like here:
compiler::enableJIT(0)
fun <- function(x) {
local(sys.calls())
That's about it. The plan is to modify the interpreter to do the same
so the inconsistency will go away. Code that is affected by this is
making assumptions that it should not.
Best,
luke
On Fri, 11 Nov 2016, Winston Chang wrote:
It looks like the byte compiler is optimizing local() to an
imm
