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
to
dual-license packages with both an OSI-approved license and
whatever-else-you-like, e.g. 'MIT | ', but IIUC
there's a bunch more complexity there than just using an OSI-approved
license.
Karl
On Tue, Jan 17, 2017 at 3:35 PM, Uwe Ligges
wrote:
>
>
> On 18.01.2017 00:13, Ka
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
LLs assume that the
associated namespace exists.
Currently 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
wrote:
> On Tue, Dec 20, 2016 at 7:39 AM, K
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
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
Bug submitted. Thanks.
On Tue, Sep 23, 2014 at 12:42 PM, Duncan Murdoch
wrote:
> On 23/09/2014 3:20 PM, Karl Millar wrote:
>>
>> This patch is against current svn and contains three classes of fix:
>> - Ensure the result is properly terminated after calls to strncpy()
&
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
Given the version / dated snapshots of CRAN, and an agreement that
reproducibility is the responsibility of the study author, the author
simply needs to sync all their packages to a chosen date, run the analysis
and publish the chosen date. It is true that this doesn't include
compilers, OS, syste
I think what you really want here is the ability to easily identify
and sync to CRAN snapshots.
The easy way to do this is setup a CRAN mirror, but back it up with
version control, so that it's easy to reproduce the exact state of
CRAN at any given point in time. CRAN's not particularly large and
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 t
Romain,
Can you use int64_t and uint_t64 instead? IMHO that would be more useful
than long long anyway.
Karl
On Sep 19, 2013 5:33 PM, "Patrick Welche" wrote:
> On Fri, Sep 20, 2013 at 12:51:52AM +0200, rom...@r-enthusiasts.com wrote:
> > In Rcpp we'd like to do something useful for types such
On Fri, Sep 6, 2013 at 7:03 PM, Duncan Murdoch wrote:
> On 13-09-06 9:21 PM, Karl Millar wrote:
>>
>> Hi Duncan,
>>
>> I like the interface of this version a lot better, but there's still a
>> bunch of implementation details that need fixing:
>>
>&
Hi Duncan,
I like the interface of this version a lot better, but there's still a
bunch of implementation details that need fixing:
* As previously mentioned, there are important cases where the mtime
values change in ways that this code doesn't detect.
* If the timestamp file (which is usually i
Comments inline:
On Wed, Sep 4, 2013 at 6:10 PM, Duncan Murdoch wrote:
>
> On 13-09-04 8:02 PM, Karl Millar wrote:
>>
>> Hi Duncan,
>>
>> I think this functionality would be much easier to use and understand if
>> you split it up the functionality of taking
Hi Duncan,
I think this functionality would be much easier to use and understand if
you split it up the functionality of taking snapshots and comparing them
into separate functions. In addition, the 'timestamp' functionality seems
both confusing and brittle to me. I think it would be better to s
25 matches
Mail list logo
