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
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
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
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
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 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
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 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
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
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
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
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
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
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 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
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, 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.
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, 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, 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 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
21 matches
Mail list logo
