Hello,
As I understand it, gettext() is designed to retrieve messages from
'R-pkg' domains. As such, it cannot retrieve some of the messages in the
'pkg' domains (those supposed to be accessed by C code only, I know),
namely, all messages ending with space(s) or \n. This is clearly
indicated
On Sun, 30 Dec 2007, Philippe Grosjean wrote:
Hello,
As I understand it, gettext() is designed to retrieve messages from
'R-pkg' domains. As such, it cannot retrieve some of the messages in the
'pkg' domains (those supposed to be accessed by C code only, I know),
namely, all messages ending
Prof Brian Ripley wrote:
On Sun, 30 Dec 2007, Philippe Grosjean wrote:
Hello,
As I understand it, gettext() is designed to retrieve messages from
'R-pkg' domains. As such, it cannot retrieve some of the messages in the
'pkg' domains (those supposed to be accessed by C code only, I know),
The netcdf code is rather silly: it uses 64-bit versions of seek etc when
building a DLL, not on Windows. I can rebuild it using 64-bit seek, but
could you please send me (privately) a test case?
On Sat, 29 Dec 2007, Thomas Lumley wrote:
Has anyone successfully used R to access netCDF files
Brian,
On Dec 29, 2007, at 12:28 PM, Prof Brian Ripley wrote:
On Sat, 29 Dec 2007, Simon Urbanek wrote:
Oops, this was supposed to be a private reply ;) - sorry about the
noise. The essence in English:
JGR uses all strings in UTF-8 encoding, but the system locale reports
CP1252 which
On Dec 30, 2007, at 12:23 AM, 程晓明 wrote:
I realize the communication between R and Java with Rserve in my
dissertation, but i can not run the Rserve by double click of
Rserve.exe,
Use
library(Rserve)
Rserve()
instead. You need to setup PATH correctly in order to run it manually
-
All,
I am still having trouble dyn.load'ing some code into R. I have
isolated the problem, I wonder if someone could explain what I am
seeing.
I think the problem is that a symbol defined in my compiled code
clashes with one already defined in R. The result is that the function
in
Matt,
On Dec 30, 2007, at 5:25 PM, Matt Calder wrote:
I am still having trouble dyn.load'ing some code into R. I have
isolated the problem, I wonder if someone could explain what I am
seeing.
I think the problem is that a symbol defined in my compiled code
clashes with one
Simon,
Thanks for the reply. Indeed, declaring the function static fixes the
example. Unfortunately, the real problem that gave rise to the example
arises in a large Fortran library that is not under my control (ARPACK).
The author is providing BLAS and LAPACK functionality intentionally.
R-devel,
I would like to second Gabor Grothendieck's request from September (
http://www.nabble.com/as.Date.numeric-to12962733.html#a12962733 )
on adding a default value (1970-01-01) to the origin argument of
as.Date.numeric.
I realize there is good reason to allow for origin to be specified,
10 matches
Mail list logo
