This is indeed unfortunate, but expecting Chinese speakers (20% of the
world's population) to write in Latin-1 was also unfortunate.
What I had (and still have) some hope of doing is being able to mark
character strings as UTF-8, probably via a flag bit on the CHARSXP. Then
output routines co
I just updated my copy of Cygwin to the latest version, and now Windows
builds are failing on that machine. The only parts of the R toolset I
changed were the Cygwin dlls. I haven't tracked down exactly what the
problem is, and probably won't be able to do so for a few days.
So if you're a Wi
Is this not supposed to work?
> dput(BOD, file = "/BOD.R")
> source("/BOD.R")
Error in attributes(.Data) <- c(attributes(.Data), attrib) :
row names must be 'character' or 'integer', not 'double'
> dput(iris, file = "/iris.R")
> source("/iris.R")
Error in attributes(.Data) <- c(attributes
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> Is this not supposed to work?
>
> > dput(BOD, file = "/BOD.R")
> > source("/BOD.R")
> Error in attributes(.Data) <- c(attributes(.Data), attrib) :
> row names must be 'character' or 'integer', not 'double'
>
> > dput(iris, file = "/iris.
Thanks.
However, that still leaves these questions:
1. I assume the changes to the internal representation of rownames is
behind this but should not dput continue to work exactly the same as
it used to work??? I would think that the internal representation aspect
would be just that -- internal a
Peter Dalgaard wrote:
>"Charles C. Berry" <[EMAIL PROTECTED]> writes:
>
>
>
>>On Tue, 24 Oct 2006, Duncan Murdoch wrote:
>>
>>
>
>
>
>>>with no defaults. However, this little demo illustrates the point, I think:
>>>
>>>
>>>
g <- function(gnodef, gdef=1) {
>>>
Hi everyone,
I am trying to cross-compile a package I wrote using the Yan and Rossini
tutorial "Building Microsoft Windows versions of R and R packages using
Intel Linux". I have got reasonably far with this but when doing the
linking using the line:
i586-mingw32-g++ -shared -s -o mylibr
You can do it like this:
> as.missing <- force
> g <- function(x = as.missing()) missing(x)
> g(3)
[1] FALSE
> g()
[1] TRUE
On 10/24/06, Paul Gilbert <[EMAIL PROTECTED]> wrote:
> (I'm not sure if this is a request for a feature, or another instance
> where a feature has eluded me for many years.)
Full_Name: Larry Layne
Version: 2.4.0
OS: MS Windows 2000
Submission from: (NULL) (129.24.91.249)
All of the following libraries loaded just fine in version 2.3.1:
> utils:::menuInstallLocal()
package 'tripack' successfully unpacked and MD5 sums checked
updating HTML package descriptions
> libra
Dear Tom,
It has worked for me out-of-the box in at least two times, one a while ago
with R-2.2-something and recently with R-2.4.0. In both cases, I was running
Debian (with a mix of testing and unstable) on x86. I never had to do
anything, just run the script and at least in one case I did cr
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> Thanks.
>
> However, that still leaves these questions:
>
> 1. I assume the changes to the internal representation of rownames is
> behind this but should not dput continue to work exactly the same as
> it used to work??? I would think that the
Thanks for your reply, as an example it appears to have difficulty linking
to even ostream library of the standard C++, as shown below:
/home/tmccallum/ritzel/RItzel/src/Classifier.cpp:209: undefined reference
to `_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc'
Classifier.o: In functi
On Wed, 25 Oct 2006 [EMAIL PROTECTED] wrote:
> Full_Name: Larry Layne
> Version: 2.4.0
> OS: MS Windows 2000
> Submission from: (NULL) (129.24.91.249)
>
>
> All of the following libraries loaded just fine in version 2.3.1:
Not a bug. For sp in particular, please simply re-install the contribute
Some of the packages needed to be newer, as you indicated. Thanks.
--On Wednesday, October 25, 2006 7:49 PM +0200 Roger Bivand
<[EMAIL PROTECTED]> wrote:
> On Wed, 25 Oct 2006 [EMAIL PROTECTED] wrote:
>
>> Full_Name: Larry Layne
>> Version: 2.4.0
>> OS: MS Windows 2000
>> Submission from: (NULL)
Hi all,
In some circumstances, as.character applied to a list converts real
NA's into the string "NA". Propagation of NAs is something R does
very well and unless there are good reasons for losing the NA, it
would improve the consistency w.r.t. NA handling for as.character to
behave differently.
Hi ALL,
To fit proportional hazard Cox Model with counting
process style of input data R and S-plus implement
"(TStart,Tstop] algorithm" (agfit3.c) which uses
"smart subsets" of sorted events time. Are there any
accessible publications where the idea of this
algorithm was represented ?
Thank yo
Seth Falcon <[EMAIL PROTECTED]> writes:
> Hi all,
>
> In some circumstances, as.character applied to a list converts real
> NA's into the string "NA". Propagation of NAs is something R does
> very well and unless there are good reasons for losing the NA, it
> would improve the consistency w.r.t.
Suppose we have a function such as the following
F <- function(f, x) f(x)+1
which runs function f and then transforms it. I would like the
corresponding function which works the same except that
unlike F returns an invisible result if and only if f does.
Is there some way of determining whether
On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> Suppose we have a function such as the following
>
> F <- function(f, x) f(x)+1
>
> which runs function f and then transforms it. I would like the
> corresponding function which works the same except that
> unlike F returns an invisi
Also, Splus 7 has a different behaviour from R:
> sapply(v, is.na)
a b c
F T T
> sapply(as.character(v), is.na)
[1] F F F
> as.character(v)
[1] "\"NA\"" "NA" "NA"
In R, it remains logical: if it isn't in character mode, then
as.character always turns NA's into "NA"'s. If that behaviour is no
Okay ... I'll try to attach that patch once more ... (does this list
only accept certain exertions for attachments? I used '.patch', but it
must have been filtered off, so I'll try '.patch.txt' now ...)
+mt
Index: R/src/library/base/man/character.Rd
==
On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > Suppose we have a function such as the following
> >
> > F <- function(f, x) f(x)+1
> >
> > which runs function f and then transforms it. I would like the
> > corresponding func
I'm observing the following on different platforms:
> parse(text='"\\x7F"')
expression("\177")
> parse(text='"\\x80"')
Error: invalid multibyte string
...
> parse(text='"\\xFF"')
Error: invalid multibyte string
However,
cat("\x7F\n\x80\n...\xFF\n")
works. Using R --vanilla.
SYSTEMS GIVING THE
On 10/25/2006 8:14 PM, Gabor Grothendieck wrote:
> Suppose we have a function such as the following
>
> F <- function(f, x) f(x)+1
>
> which runs function f and then transforms it. I would like the
> corresponding function which works the same except that
> unlike F returns an invisible result i
On 10/25/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 10/25/2006 8:14 PM, Gabor Grothendieck wrote:
> > Suppose we have a function such as the following
> >
> > F <- function(f, x) f(x)+1
> >
> > which runs function f and then transforms it. I would like the
> > corresponding function which
On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > Suppose we have a function such as the following
> >
> > F <- function(f, x) f(x)+1
> >
> > which runs function f and then transforms it. I would like the
> > corresponding func
On Wed, 2006-10-25 at 19:16 -0700, Deepayan Sarkar wrote:
> On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> > On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > > Suppose we have a function such as the following
> > >
> > > F <- function(f, x) f(x)+1
> > >
> > > which runs fun
On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-10-25 at 19:16 -0700, Deepayan Sarkar wrote:
> > On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > > > Suppose we have a function such as the following
> >
On 10/25/2006 11:02 PM, Gabor Grothendieck wrote:
> On 10/25/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> On 10/25/2006 8:14 PM, Gabor Grothendieck wrote:
>>> Suppose we have a function such as the following
>>>
>>> F <- function(f, x) f(x)+1
>>>
>>> which runs function f and then transforms it
Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> I just updated my copy of Cygwin to the latest version, and now Windows
> builds are failing on that machine. The only parts of the R toolset I
> changed were the Cygwin dlls. I haven't tracked down exactly what the
> problem is, and probably won't b
30 matches
Mail list logo
