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,
and also i can't realize backstage running of Rserve by technique of
Multi-thread in Java. Can anyone tell me why?
So, before i run the Java, i must run
Has anyone successfully used R to access netCDF files larger than 2Gb under
Windows?
With the version of the ncdf package that Brian Ripley provides for CRAN extras
I get an assertion failure with a 12Gb file, but not a 1Gb subset of it. The
same 12Gb file is ok with ncdf on Mac OS X (32bit R)
In ?options, one reads warnings.length, but it should be warning.length.
Version:
platform = i386-apple-darwin8.10.1
arch = i386
os = darwin8.10.1
system = i386, darwin8.10.1
status =
major = 2
minor = 6.1
year = 2007
month = 11
day = 26
svn rev = 43537
language = R
versi
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 impedes automatic conversions (because R doesn't know
that everything is
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 impedes automatic conversions (because R doesn't know
that everything is UTF-8). Specific conversion via iconv w
Hallo Matthias,
On Dec 27, 2007, at 3:52 PM, Matthias Wendel wrote:
> Hi, simon,
> i followed your advice by adding/changing the lines
> abt = iconv(abt,"utf-8","latin1")
> zz = file( paste("Itemtabelle/Itemtabelle", abt, ".html"), "wt",
> encoding = "latin1")
> but this yielded the s
Dear R Team,
The installation of the packages ade4 and ecodist failed with the
message that the description file could not be read.
The problem appeared with recent versions of R (2.6.0 or 2.6.1)
- On a Macintosh computer, trying to install packages directly
through the internet
- On a Windows
On Sat, 29 Dec 2007, Philippe Grosjean wrote:
> Thank you, Brian.
>
> Prof Brian Ripley wrote:
>> This only happens if 'file' is a text connection, and is the expected
>> behaviour in that case: you cannot capture an incomplete line to a text
>> connection.
>
> Well, in ?textConnection, Details
On Sat, 29 Dec 2007, Martin Maechler wrote:
>> "BDR" == Brian Ripley <[EMAIL PROTECTED]>
>> on Sat, 29 Dec 2007 13:20:14 +0100 (CET) writes:
>
>BDR> This only happens if 'file' is a text connection, and
>BDR> is the expected behaviour in that case: you cannot
>BDR> capture
> "BDR" == Brian Ripley <[EMAIL PROTECTED]>
> on Sat, 29 Dec 2007 13:20:14 +0100 (CET) writes:
BDR> This only happens if 'file' is a text connection, and
BDR> is the expected behaviour in that case: you cannot
BDR> capture an incomplete line to a text connection.
BDR>
Thank you, Brian.
Prof Brian Ripley wrote:
> This only happens if 'file' is a text connection, and is the expected
> behaviour in that case: you cannot capture an incomplete line to a text
> connection.
Well, in ?textConnection, Details section, one can read:
"Closing the connection will output
This only happens if 'file' is a text connection, and is the expected
behaviour in that case: you cannot capture an incomplete line to a text
connection.
There seems no reason to break the documented behaviour in other cases to
change something that you consider to a bug when file=NULL and the
Full_Name: Philippe Grosjean
Version: 2.6.1
OS: MacOS X; Windows XP
Submission from: (NULL) (81.243.237.235)
Last output from capture.output() is truncated if it does not end with a
carriage return:
> capture.output(cat("text\n")) # Fine
[1] "text"
> capture.output(cat("text"))# Missing out
13 matches
Mail list logo
