FWIW, the package-building tools in the 'mvbutils' package-- see
?mvbutils.packaging.tools-- are supposed to alleviate much of this (provided of
course you are willing to sign up to MY view of the universe...). Building a
"legal" package out of existing code from scratch takes me less than 5 min
Hi,
Say we want to supply a generic plot() in a package with a simple class,
like this:
------
setClass("track",
representation=representation(x="numeric", y="numeric"))
if (!isGeneric("plot")) {
setGeneric("plot",
Hi,
Is there any reason why tar() and untar() don't use the
same environment variable?
Usage:
tar(tarfile, files = NULL,
compression = c("none", "gzip", "bzip2", "xz"),
compression_level = 6, tar = Sys.getenv("tar"))
Usage:
untar(tarfile, files = NULL, list = FALSE
I agree with Kevin, I never run package.skeleton more than once. But
one advantage to running it over and over again is if you change the
names or the ordering of function arguments. That gets autowritten
and I could see that being convenient if you change those a lot (as
you sometime do in devel
The phrase that caught my attention in your post is the one about
"running package.skeleton() over and over". When I'm developing
packages, I never run it more than once. And I usually delete a lot of
the files it produces (since I like to organize my functions in logical
batches and not in
On 16/09/2010 2:45 PM, William Dunlap wrote:
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Janko Thyson
> Sent: Thursday, September 16, 2010 11:19 AM
> To: r-de...@r-project. org
> Subject: Re: [Rd] a small suggestion for improving the
> buildi
> -Ursprüngliche Nachricht-
> Von: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Gesendet: Donnerstag, 16. September 2010 20:55
> An: Uwe Ligges
> Cc: Janko Thyson; r-de...@r-project. org
> Betreff: Re: [Rd] a small suggestion for improving the building of
> packages
>
> On 16/09/20
> -Ursprüngliche Nachricht-
> Von: William Dunlap [mailto:wdun...@tibco.com]
> Gesendet: Donnerstag, 16. September 2010 20:45
> An: Janko Thyson; r-de...@r-project. org
> Betreff: RE: [Rd] a small suggestion for improving the building of
> packages
>
> > From: r-devel-boun...@r-project.o
On 16/09/2010 2:43 PM, Uwe Ligges wrote:
On 16.09.2010 20:18, Janko Thyson wrote:
>> From: Uwe Ligges
>> Date: Wed, 15 Sep 2010 15:23:01 +0200
>> On 29.08.2010 22:34, Kyle Matoba wrote:
>>> All,
>>>
>>> I just finished the process of build a package for the first time and
>> found
>>> it
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Janko Thyson
> Sent: Thursday, September 16, 2010 11:19 AM
> To: r-de...@r-project. org
> Subject: Re: [Rd] a small suggestion for improving the
> building of packages
...
> Dear Uwe,
> in principle, I to
On 16.09.2010 20:18, Janko Thyson wrote:
From: Uwe Ligges
Date: Wed, 15 Sep 2010 15:23:01 +0200
On 29.08.2010 22:34, Kyle Matoba wrote:
All,
I just finished the process of build a package for the first time and
found
it characteristically (for R) very straightforward and well
documented.
> From: Uwe Ligges
> Date: Wed, 15 Sep 2010 15:23:01 +0200
> On 29.08.2010 22:34, Kyle Matoba wrote:
> > All,
> >
> > I just finished the process of build a package for the first time and
> found
> > it characteristically (for R) very straightforward and well
> documented.
> >
> > Whenever I deal
Since you are using git you may want to consider a submodule for your project.
It is often helpful to build a full library in c++ complete with it's
own unit tests.
You can then package this library inside of your R project as a submodule.
This can speed up the testing phase of the project b/c y
Hello,
I have a package with a namespace. Because I use Roxygen that overwrites the
NAMESPACE file each time it is run, I use a R/zzz.R file with
an .onLoad() and .onUnload() functions to take care of loading and unloading
my shared library.
The problem: if I load my library from a local director
On 16.09.2010 17:05, Martyn Plummer wrote:
Dear Thomas,
Is this the deSolve package?
http://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/deSolve-00check.html
I can help you with that. It does pass R CMD check on my OpenSolaris
installation, but I am getting some compiler warnings. I w
On Sep 16, 2010, at 10:06 AM, Vinh Nguyen wrote:
> Dear all,
>
> As I resume my dissertation work next month, I'd like to actually
> start an R package this time around. I haven't done so because I
> update my code very often (still in development phase), so running the
> skeleton function, runn
Dear Thomas,
Is this the deSolve package?
http://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/deSolve-00check.html
I can help you with that. It does pass R CMD check on my OpenSolaris
installation, but I am getting some compiler warnings. I will send you
details.
Martyn
On Thu, 2010-0
Dear all,
As I resume my dissertation work next month, I'd like to actually
start an R package this time around. I haven't done so because I
update my code very often (still in development phase), so running the
skeleton function, running checks, building, and re-installing the
package onto the s
Hi,
I'm trying to build R with Radford Neal's patches. I did successful
before on Win, but with 2.11.1 version i got some problems. So my next
try was cross build on Linux. (without patches, yet)
I use: ./configure --build i686-pc-linux-gnu --host i686-pc-mingw32 --with-x=no
And get:
configure: WA
Dear R developers,
we have currently a 'mysterious' test problem with one package that
successfully passed the tests on all platforms, with the only exception
of Solaris x86 where obviously one of our help examples breaks the CRAN
test.
As we don't own such a machine I want to ask about a po
In the course of some work I have been doing for Revolution Analytics I have
had the necessity of modifying the plm function so that it would not die
halfway through fitting. In particular, I was able to more than halve the
runtime (for my particular run) and improve its memory usage with three
sm
21 matches
Mail list logo
