> But beware that a function makes a copy of the argument as soon as you try to
> modify something in that argument. So, for example, if you have a big list
> object as an argument and are going to modify one element in the list, you
> will save memory by making a local copy of the single elemen
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
> project.org] On Behalf Of Gabriel Becker
> Sent: July 22, 2011 11:38 AM
> To: Spencer Graves
> Cc: Alireza Mahani; r-devel@r-project.org
> Subject: Re: [Rd] Best practices for writing R functions
>
> On
On Fri, Jul 22, 2011 at 8:14 AM, Spencer Graves wrote:
> From my personal experience and following this list some for a few
> years, the best practice is initially to ignore the compute time question,
> because the cost of your time getting it to do what you want is far greater,
> at least i
On Jul 22, 2011, at 9:26 AM, Alireza Mahani wrote:
> I am developing an R package for internal use, and eventually for public
> release. My understanding is that there is no easy way to avoid copying
> function arguments in R (i.e. we don't have the concept of pointers in R),
> which makes me war
From my personal experience and following this list some for a
few years, the best practice is initially to ignore the compute time
question, because the cost of your time getting it to do what you want
is far greater, at least initially. Don't worry about compute time
until it becomes a
I am developing an R package for internal use, and eventually for public
release. My understanding is that there is no easy way to avoid copying
function arguments in R (i.e. we don't have the concept of pointers in R),
which makes me wary of freely creating chains of function calls since each
func
Connections use finalizers for cleanup. Once finalizers become
eligible to run, the order in which they are run is unspecified. If
you want to be sure yours runs first then you need to make sure the
connection one doesn't become eligible to run until yours has.
Best,
luke
On Thu, 21 Jul 2011,
One possibility is that you are building from a tarball snapshot
without mentioning it, and the (unspecified) tarball is incomplete.
For R-devel using tarballs is not a wise idea: they are really only
checked carefully in pre-release periods. (One of the checks is that
AFAIR CRAN builds from
It does not seem to happen to anyone else, including me on FreeBSD.
Is this a completely clean install? src/library/datasets/Makefile
definitely installs a NAMESPACE file as part of the mkR1 target, so I
would check that you have a src/library/datasets/NAMESPACE file in
your sources.
(There
After building and installing R-devel from 21/07/2011 on FreeBSD
9.0-CURRENT (amd64), starting R gives the following warning:
[..snip..]
Beim Start - Warnmeldung:
package 'datasets' in options("defaultPackages") was not found
This happens with all versions after 14/07/2011. I think it is relate
10 matches
Mail list logo
