See inlin
e
On Tue, Dec 20, 2016 at 12:14 PM, Spencer Graves <
spencer.gra...@prodsyse.com> wrote:
> Hi, Dirk:
>
>
>
> On 12/20/2016 10:56 AM, Dirk Eddelbuettel wrote:
>
>> On 20 December 2016 at 17:40, Martin Maechler wrote:
>> | > Steve Bronder
>> | > on Tue, 20 Dec 2016 01:34:3
Hi, Dirk:
On 12/20/2016 10:56 AM, Dirk Eddelbuettel wrote:
On 20 December 2016 at 17:40, Martin Maechler wrote:
| > Steve Bronder
| > on Tue, 20 Dec 2016 01:34:31 -0500 writes:
|
| > Thanks Henrik this is very helpful! I will try this out on our tests and
| > see if gcDLLs(
On 20 December 2016 at 17:40, Martin Maechler wrote:
| > Steve Bronder
| > on Tue, 20 Dec 2016 01:34:31 -0500 writes:
|
| > Thanks Henrik this is very helpful! I will try this out on our tests and
| > see if gcDLLs() has a positive effect.
|
| > mlr currently has tests b
> Steve Bronder
> on Tue, 20 Dec 2016 01:34:31 -0500 writes:
> Thanks Henrik this is very helpful! I will try this out on our tests and
> see if gcDLLs() has a positive effect.
> mlr currently has tests broken down by learner type such as
classification,
> regression
It's not always clear when it's safe to remove the DLL.
The main problem that I'm aware of is that native objects with
finalizers might still exist (created by R_RegisterCFinalizer etc).
Even if there are no live references to such objects (which would be
hard to verify), it still wouldn't be safe
Hi all,
I believe there is an issue with passing NULL to the function I().
class(NULL) # "NULL" (as expected)
print(NULL) # NULL (as expected)
is.null(NULL) # TRUE (as expected)
According to the documentation I() should return a copy of its input
with class "AsIs" preprended:
class(I(NULL
Hi all,
I have noticed incorrect parsing of very small hexadecimal numbers
like "0x1.dp-987". Such a hexadecimal representation can
can be produced by sprintf() using the %a flag. The return value is
incorrectly reported as 0 when coercing these numbers to double using
as.double()/as.n
On Tue, Dec 20, 2016 at 7:04 AM, Henrik Bengtsson
wrote:
> On reason for hitting the MAX_NUM_DLLS (= 100) limit is because some
> packages don't unload their DLLs when they being unloaded themselves.
I am surprised by this. Why does R not do this automatically? What is
the case for keeping the DL
