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 pbrun...@gmail.com
wrote:
If you link to tcmalloc instead of the default malloc on your system, the
performance of large allocations should improve. On unix machines you
don't even need to recompile -- you can do this with LD_PRELOAD. The
downside is that you'll almost certainly end up with higher average memory
usage.as
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
<maech...@stat.math.ethz.ch> wrote:
>>>>>> Karl Millar via R-devel <r-devel@r-pro
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
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
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
; R-devel <r-devel@r-project.org> wrote:
>>
>>> In S-PLUS 3.4 help on 'c' (http://www.uni-muenster.de/
>>> ZIV.BennoSueselbeck/s-html/helpfiles/c.html), there is no 'use.names'
>>> argument.
>>>
>>> Because 'c' is a generic function, I don't think
'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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
IIUC, loading a namespace automatically registers all the exported
methods as long as the generic can be found when the namespace gets
loaded. Generics can be exported and imported as regular functions.
In that case, code in a package should be able to simply import the
generic and the methods
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
It does, but you'd still be relying on the R code ensuring that all of
these objects are dead prior to unloading the DLL, otherwise they'll
survive the GC. Maybe if the package counted how many such objects
exist, it could work out when it's safe to remove the DLL. I'm not
sure that it can be
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
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
13 matches
Mail list logo
