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
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
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 presuma
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 don
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
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
re
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 wi
>
>>> 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 that chang
'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
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
wrote:
>>>>>> Karl Millar via R-devel
>>>>>>
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
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
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, J
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
wrote:
>
> Dear R contribu
14 matches
Mail list logo
