RDieHarder fails its regression tests on x86_64 (aka "amd64") at CRAN (using
Debian), and I see the same on Ubuntu 8.10 in 64 bit. No issues on 32bit.
One odd thing is that the program behaves well if run via
R --no-save < tests/RDieHarder.R
but NOT when started using
R --slave < tes
Here are more specific details: I use GNU/Linux Ubuntu 8.04 on an x86_64
workstation. R environnement was compiled from 2.8.0 sources.
Below is a part of my C code to test the file I/O.
When compiled as a standalone executable it prints "Test1" on the
console and generates "test.txt" and "t
Mathieu,
I do not understand what you mean in your email.
I am only interested in the cause of the valgrind
message in
> .Call("XXX")
[1] 1
> nd <- 3
> solve(diag(nd) , as.vector(1:nd))
[1] 1 2 3
> .Call("XXX")
==25734== Conditional jump or move depends on uninitialised value(s)
==25734==at 0
Hi Mathieu,
Very strange.
(i) The whole package RandomFields is written with ` extern "C" '
and seems working. There is no message from valgrind
anywhere, except in two situations that I have boiled
down to the code in the bug report.
(ii) without ` extern "C" ' I get a warning plus an
On Wed, 28 Jan 2009, Benjamin Leblanc wrote:
Hello all,
I am getting into trouble when trying to do standard I/O from a C function
called within R environment.
This function is written in a small C library that is loaded whith dyn.load()
and called in R via the .C() interface. I need to debu
Hi,
Due to the recent release of RMySQL 0.7-2 and incompatibilities with the
MySQL client libraries, I'm planning the following change:
Load-time check of compiled vs. loaded MySQL client library version.
The client library version is an integer value with the format XYYZZ
where X is the maj
Hello all,
I am getting into trouble when trying to do standard I/O from a C
function called within R environment.
This function is written in a small C library that is loaded whith
dyn.load() and called in R via the .C() interface. I need to debug the C
code using a text file for some logs,
Hola!
I decided to abandon (orphane) the maintenance of the cran asypow package.
If anybody is interested they can take over now!
reason (among others): I do now my power calculations by simulation
and find that more flexible and fast enough.
Kjetil
[[alternative HTML version deleted]]
Hi Martin,
Sorry I was stupid. Indeed, I named the file tom.c instead of tmp.cc.
Now with the right extension, it works with the 'extern "C"' piece of code.
However, for your (ii) point, this shouldn't be related to the omission
of 'extern "C"' but to the fact that the shared library is not l
