On Aug 3, 2006, at 7:54 PM, Kevin B. Hendricks wrote:
> ---> STOR Rigroup_0.80.0.tar.gz
> 553 Could not create file.
If you unsuccessfully attempted to upload a file once but got
connected, it will prevent you from trying it again as the file
already exists.
FWIW on a Mac (or any machine wi
Le Mercredi 2 Août 2006 21:33, Duncan Murdoch a écrit :
> On 8/2/2006 6:05 PM, Hin-Tak Leung wrote:
> > Uwe Ligges wrote:
> >
> >
> >> I cannot imagine: Why should one want to perform difficult cross
> >> compiling if you have Windows available?
> >> And why should I run R under wine? If I like Wi
Yes, I was able to upload test.dat just now. I am using the FileZilla
ftp client on a Windows XP machine.
On 8/3/06, Kevin B. Hendricks <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Thanks anyway but I can connect as well and was even able to cd into
> incoming but it would not allow me upload any files.
Hi,
Thanks anyway but I can connect as well and was even able to cd into
incoming but it would not allow me upload any files. That is what
the debug log showed below.
Can you upload things into incoming? Perhaps there is simply
something funny about my ftp client? I will try from my MacO
Its ftp://cran.r-project.org/incoming . Its listed at the bottom of:
the mirrors page: http://cran.r-project.org/mirrors.html
I just tried it and got connected.
On 8/3/06, Kevin B. Hendricks <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I found a web page that said to upload using ftp to cran.r-
> project
That's, in fact, the way seq.dates works in the chron package:
library(chron)
x <- chron("01/31/2006")
seq(x, by = "month", length = 2) # 01/31/06 02/28/06
See the help desk article in R News 4/1 for more about the main
date classes.
On 8/3/06, Ponzio, Stephen [CIB-LAVA] <[EMAIL PROTECTED]> w
Hi,
I found a web page that said to upload using ftp to cran.r-
project.org/incoming
Unfortunately, I can't seem to do that either.
[EMAIL PROTECTED] src]$ ftp -d cran.r-project.org
Connected to cran.wu-wien.ac.at.
220 Welcome to the CRAN FTP service.
---> AUTH GSSAPI
530 Please login with USER
Hi,
Thanks to lots of help and hints, I now have a working validated
external version of all of the igroup functions. The source Package
is called Rigroup_0.80.0.tar.gz and it passes R CMD check of my Linux
box and will install and pass all tests on my Mac OSX(Intel and PPC)
machines and
That is not what I think those lines indicate in R-patched. They are all
(in my copy, r38783, unchanged since r38499, 2006-07-06)
case sizeof(long):
and all protected by
#if SIZEOF_LONG == 8
So the compiler used to do the configure and that used to do the
compilation think 'long'
Duncan Murdoch wrote:
> I have just updated the MinGW tools to the latest versions. These don't
> include a patch that was intended to ensure NT 4 compatibility, but I
> don't know if the patch is still necessary.
>
> If anyone is still using NT4, could you please download R-patched, and
> s
Is this a desirable change?
I would have expected sort to be equivalent to using order.
Thanks,
Stephen
-Original Message-
From: Duncan Murdoch [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 03, 2006 11:33 AM
To: Ponzio, Stephen [CIB-LAVA]
Cc: r-devel@stat.math.ethz.ch; [EMAIL PROTECT
You're right, it's tricky.
I guess I would expect Jan. 30 + 1 month = Feb. 28.
Of couse, then Jan. 30 + 1 month = Jan. 28 + 1 month;
I understand.
Being that "1 month" is imprecise in terms of number of days,
this anomaly is preferable to skipping months (Jan. 30 + 1 month = March 2),
in my opi
Definitely not a bug. You seem to expect seq.Date to have an entirely
different convention depending on whether you are at the beginning of
the month or at the end of the month, which does not seem reasonable to
me.
For instance, does adding a month to Feb 28th give March 28th or March
31st? Given
On 8/3/2006 10:26 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Stephen Ponzio
> Version: 2.3.1
> OS: Windows
> Submission from: (NULL) (199.67.138.42)
>
>
> With the option by="1 month" and a date that is the 31st,
> the function seq doesn't give the last day of successive months,
> as I would exp
On 8/3/2006 10:34 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Stephen Ponzio
> Version: 2.3.1
> OS: Windows
> Submission from: (NULL) (199.67.138.42)
>
>
> Given a vector of dates, sort returns a vector of numerics instead of dates.
> This is different from the behavior in version 2.2, where dates
Full_Name: Stephen Ponzio
Version: 2.3.1
OS: Windows
Submission from: (NULL) (199.67.138.42)
Given a vector of dates, sort returns a vector of numerics instead of dates.
This is different from the behavior in version 2.2, where dates were returned.
In this respect, sort is not equivalent to order
Full_Name: Stephen Ponzio
Version: 2.3.1
OS: Windows
Submission from: (NULL) (199.67.138.42)
With the option by="1 month" and a date that is the 31st,
the function seq doesn't give the last day of successive months,
as I would expect it should:
> Sys.Date()
[1] "2006-08-03"
> Sys.Date()-3
[1]
I have just updated the MinGW tools to the latest versions. These don't
include a patch that was intended to ensure NT 4 compatibility, but I
don't know if the patch is still necessary.
If anyone is still using NT4, could you please download R-patched, and
see if it runs on your system? As of
Full_Name: Stefan Albrecht
Version: 2.3.1
OS: Windows XP
Submission from: (NULL) (194.127.2.74)
Dear Bug-Team,
in the function rgb() the argument names is only applied, when alpha is not
missing.
This is due to the substr() applied at the end, which deletes the names of
result.
I guess that pre
On Wed, 2 Aug 2006, Paul Murrell wrote:
> Hi
>
>
> Roger Bivand wrote:
> > This issue is probably to do with on-screen viewing of PDF files written
> > from R (2.3.1, Windows XP, RHEL 4), not with how the files are produced.
> > So the question is mainly to ask whether others have seen similar
20 matches
Mail list logo
