On Mon, Jan 17, 2011 at 7:00 PM, Spencer Graves <
spencer.gra...@structuremonitoring.com> wrote:
> Hi, Dominick, et al.:
>
>
> Demanding complete unit test suites with all software contributed to
> CRAN would likely cut contributions by a factor of 10 or 100. For me, the R
> package creation
Hi, Dominick, et al.:
Demanding complete unit test suites with all software contributed
to CRAN would likely cut contributions by a factor of 10 or 100. For
me, the R package creation process is close to perfection in providing a
standard process for documentation with places for examp
On Mon, Jan 17, 2011 at 5:15 PM, Spencer Graves <
spencer.gra...@structuremonitoring.com> wrote:
> Hi, Paul:
>
>
> The "Writing R Extensions" manual says that *.R code in a "tests"
> directory is run during "R CMD check". I suspect that many R programmers do
> this routinely. I probably sho
Hi, Paul:
The "Writing R Extensions" manual says that *.R code in a "tests"
directory is run during "R CMD check". I suspect that many R
programmers do this routinely. I probably should do that also.
However, for me, it's simpler to have everything in the "examples"
section of *.Rd
On Mon, 17 Jan 2011, Simon Urbanek wrote:
On Jan 16, 2011, at 10:41 PM, Simon Wotherspoon wrote:
I believe there is a memory leak in isoreg in the current version of R, as I
believe the following shows
gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 120405 3.3 35 9.
Spencer
Would it not be easier to include this kind of test in a small file in the
tests/ directory?
Paul
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Spencer Graves
Sent: January 17, 2011 3:58 PM
To: Dominick Samperi
Cc: Pa
On Mon, Jan 17, 2011 at 3:57 PM, Spencer Graves <
spencer.gra...@structuremonitoring.com> wrote:
> For me, a major strength of R is the package development process.
> I've found this so valuable that I created a Wikipedia entry by that name
> and made additions to a Wikipedia entry on "softw
For me, a major strength of R is the package development
process. I've found this so valuable that I created a Wikipedia entry
by that name and made additions to a Wikipedia entry on "software
repository", noting that this process encourages good software
development practices that I hav
On Mon, Jan 17, 2011 at 2:08 PM, Spencer Graves <
spencer.gra...@structuremonitoring.com> wrote:
> Another point I have not yet seen mentioned: If your code is
> painfully slow, that can often be fixed without leaving R by experimenting
> with different ways of doing the same thing -- often
On Mon, Jan 17, 2011 at 6:57 PM, David Henderson wrote:
> I think we're also forgetting something, namely testing. If you write your
> routine in C, you have placed additional burden upon yourself to test your C
> code through unit tests, etc. If you write your code in R, you still need the
> un
Another point I have not yet seen mentioned: If your code is
painfully slow, that can often be fixed without leaving R by
experimenting with different ways of doing the same thing -- often after
using profiling your code to find the slowest part as described in
chapter 3 of "Writing R Ex
I think we're also forgetting something, namely testing. If you write your
routine in C, you have placed additional burden upon yourself to test your C
code through unit tests, etc. If you write your code in R, you still need the
unit tests, but you can rely on the well tested nature of R to a
On 17 January 2011 at 09:13, Patrick Leyshock wrote:
| A question, please about development of R packages:
|
| Are there any guidelines or best practices for deciding when and why to
| implement an operation in R, vs. implementing it in C? The "Writing R
| Extensions" recommends "working in inte
On 17/01/2011 12:41 PM, Patrick Burns wrote:
Everyone has their own utility
function. Mine is if the boredom
of waiting for the pure R function
to finish is going to out-weight the
boredom of writing the C code.
Another issue is that adding C code
increases the hassle of users who might
want th
Everyone has their own utility
function. Mine is if the boredom
of waiting for the pure R function
to finish is going to out-weight the
boredom of writing the C code.
Another issue is that adding C code
increases the hassle of users who might
want the code to run on different
architectures.
On
On Mon, 17 Jan 2011, Dirk Eddelbuettel wrote:
On 16 January 2011 at 23:00, Xiaobo Gu wrote:
| Is it because of compiler campsites between R and PostgreSQL, R is
| compiled by GCC, while PostgreSQL from Enterprise DB is compiled by
| Microsoft Visual C ++.
So the usual recommendation is to buil
A question, please about development of R packages:
Are there any guidelines or best practices for deciding when and why to
implement an operation in R, vs. implementing it in C? The "Writing R
Extensions" recommends "working in interpreted R code . . . this is normally
the best option." But we
On Jan 16, 2011, at 10:41 PM, Simon Wotherspoon wrote:
>
> I believe there is a memory leak in isoreg in the current version of R, as I
> believe the following shows
>
> > gc()
> used (Mb) gc trigger (Mb) max used (Mb)
> Ncells 120405 3.3 35 9.4 35 9.4
> Vcells 78639
On 16 January 2011 at 23:00, Xiaobo Gu wrote:
| Is it because of compiler campsites between R and PostgreSQL, R is
| compiled by GCC, while PostgreSQL from Enterprise DB is compiled by
| Microsoft Visual C ++.
So the usual recommendation is to build the matching library (here libpq)
with the same
I believe there is a memory leak in isoreg in the current version of R,
as I believe the following shows
> gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 120405 3.3 35 9.4 35 9.4
Vcells 78639 0.6 786432 6.0 392463 3.0
> for(k in 1:100) {
+
+ y <- runi
Is it because of compiler campsites between R and PostgreSQL, R is
compiled by GCC, while PostgreSQL from Enterprise DB is compiled by
Microsoft Visual C ++.
Xiaobo Gu
On Sat, Jan 15, 2011 at 10:34 AM, Xiaobo Gu wrote:
> Hi,
> I build the binary package file of RPostgreSQL 0.1.7 for Windows 2003
21 matches
Mail list logo
