search for: kmillar

On Tue, Dec 20, 2016 at 7:39 AM, Karl Millar <kmillar at google.com> wrote: > 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 objec...

...rrently what I do is to never unload DLLs. If I need to replace one, then I just restart R. It's less convenient, but it's always correct. On Wed, Dec 21, 2016 at 9:10 AM, Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote: > On Tue, Dec 20, 2016 at 7:39 AM, Karl Millar <kmillar at google.com> wrote: >> 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 refe...

On Tue, Dec 20, 2016 at 7:04 AM, Henrik Bengtsson <henrik.bengtsson at gmail.com> 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 DLL loaded after the package has been unloaded? What

...explicitly documented in Dates.Rd, that has 'c.Date' as an alias. -------------------------------------------- On Sat, 24/9/16, Martin Maechler <maechler at stat.math.ethz.ch> wrote: Subject: Re: [Rd] Undocumented 'use.names' argument to c() To: "Karl Millar" <kmillar at google.com> Date: Saturday, 24 September, 2016, 9:12 PM >>>>> Karl Millar via R-devel <r-devel at r-project.org> >>>>> on Fri, 23 Sep 2016 11:12:49 -0700 writes: > I'd expect that a lot of the performance overhead could be eliminated...

I'd like to propose a change to the R language so that calling 'parent.env<-' on a package namespace or package imports is a runtime error. Currently the documentation warns that it's dangerous behaviour and might go away: The replacement function ?parent.env<-? is extremely dangerous as it can be used to destructively change environments in ways that violate

Dear R contributors, I'm running into trouble when trying to allocate some large (but in theory viable) vector in the context of C code bound to R through .Call(). Here is some sample code summarizing the problem: SEXP test() { int size = 10000000; double largevec[size]; memset(largevec, 0, size*sizeof(double)); return(R_NilValue); } If size if small enough (up to 10^6), everything is

Thanks. Couldn't you implement model.matrix(..., sparse = TRUE) with a small amount of R code similar to MatrixModels::model.Matrix ? On Mon, Feb 29, 2016 at 10:01 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote: >>>>>> Karl Millar via R-devel <r-devel at r-project.org> >>>>>> on Fri, 26 Feb 2016 15:58:20 -0800 writes: > >

Hi Pierrick, You're storing largevec on the stack, which is probably causing a stack overflow. Allocate largvec on the heap with malloc or one of the R memory allocation routines instead and it should work fine. Karl On Thu, Dec 18, 2014 at 12:00 AM, Pierrick Bruneau <pbruneau at gmail.com> wrote: > > Dear R contributors, > > I'm running into trouble when trying to

Fellipe, CXXR development has moved to github, and we haven't fixed up the build for using git yet. Could you send a pull request with your change to the repo at https://github.com/cxxr-devel/cxxr/? Also, this patch may be useful for pqR too. https://github.com/radfordneal/pqR Thanks On Mon, Jan 19, 2015 at 2:35 PM, Dirk Eddelbuettel <edd at debian.org> wrote: > > On 19

'c' has an undocumented 'use.names' argument. I'm not sure if this is a documentation or implementation bug. > c(a = 1) a 1 > c(a = 1, use.names = F) [1] 1 Karl

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 to unload the DLL until a full garbage collection has been done. If the DLL is

This patch is against current svn and contains three classes of fix: - Ensure the result is properly terminated after calls to strncpy() - Replace calls of sprintf() with snprintf() - Added a PROTECT() call in do_while which could cause memory errors if evaluating the condition results in a warning. Thanks, Karl

According to http://cran.r-project.org/doc/manuals/r-release/R-lang.html#Reserved-words if else repeat while function for in next break TRUE FALSE NULL Inf NaN NA NA_integer_ NA_real_ NA_complex_ NA_character_ ... ..1 ..2 etc. are all reserved keywords. However, in R 3.0.2 you can do things like: `if` <- function(cond, val1, val2) val2 after which if(TRUE) 1 else 2 returns 2.

A couple of points: - rebuilding dependent packages is needed if there is an ABI change, not just an API change. For packages like Rcpp which export inline functions or macros that might have changed, this is potentially any change to existing functions, but for packages like Matrix, it isn't really an issue at all IIUC. - If we're looking into a way to check if package APIs are

I'd expect that a lot of the performance overhead could be eliminated by simply improving the underlying code. IMHO, we should ignore it in deciding the API that we want here. On Fri, Sep 23, 2016 at 10:54 AM, Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote: > I'd vote for it to stay. It could of course suprise someone who'd > expect c(list(a=1), b=2, use.names =

Generating a model matrix with very large numbers of columns overflows the stack and/or runs very slowly, due to the implementation of TrimRepeats(). This patch modifies it to use Rf_duplicated() to find the duplicates. This makes the running time linear in the number of columns and eliminates the recursive function calls. Thanks -------------- next part -------------- A non-text attachment was

Is there anything that actually requires R core members to manually do significant amounts of work here? IIUC, you can do a CRAN run to detect the broken packages, and a simple script can collect the emails of the affected maintainers, so you can send a single email to them all. If authors don't respond by fixing their packages, then those packages should be archived, since there's high

Please don't use 'Unlimited' or 'Unlimited + ...'. Google's lawyers don't recognize 'Unlimited' as being open-source, so our policy doesn't allow us to use such packages due to lack of an acceptable license. To our lawyers, 'Unlimited + file LICENSE' means something very different than it presumably means to Uwe. Thanks, Karl On Sat, Jan 14,

Unfortunately, our lawyers say that they can't give legal advice in this context. My question would be, what are people looking for that the MIT or 2-clause BSD license don't provide? They're short, clear, widely accepted and very permissive. Another possibility might be to dual-license packages with both an OSI-approved license and whatever-else-you-like, e.g. 'MIT |