[Rd] boxplot by factor (Package base version 2.1.1) (PR#7976)
I consider this to be an old bug, which also persists in Splus 7. It
is unnecessary, and annoying.
## Section 1: Consider a simple data frame with three possible
factors (in levels)
d <- data.frame(a=sort(rnorm(10)*10), b=factor(c(rep("A",4), rep("C",
6)), levels=c("A","B","C")))
tapply(d$a, d$b, mean) # returns three results, which I would expect
plot(a ~ b, d) # plots only two of three objects, ignoring that there
was "C" in the second position
# if I tried to plot a blank in between the two boxplots:
plot(a ~ b, d, at=1:3) # nope: error
plot(a ~ b, d, at=c(1,3)) # nope: out of range (also xlim does
nothing for the formula boxplot method)
# to make this work with the current R/Splus implementation, I have
to add a zero:
d <- rbind(d, data.frame(a=0,b="B")) # which I don't want to do,
since there are no "B"
plot(a ~ b, d) # yuk!
## Section 2: Why is this important? Consider another realistic
example of [synthetic] daily temperature
temp <- 5 - 10*cos(1:365*2*pi/365) + rnorm(365)*3
d1 <- data.frame(year=2005, jday=1:365, date=NA, month=NA, temp) #
jday is Julian day [1,365]
d1$date <- as.Date(paste(d1$year, d1$jday), "%Y %j")
d1$month <- factor(months(d1$date,TRUE), levels=month.abb)
plot(temp ~ month, d1) # perfect, in a perfect meteorological world
d2 <- d1[!d1$month %in% c("Mar","Apr","May","Sep"),] # now let's
remove some data
tapply(d2$temp,d2$month,mean) # perfect
plot(temp ~ month, d2) # ugly, not 12 months, etc. (despite having 12
levels)
# again the only cure is to add zeros to the missing months
(unnecessary forgery of data)
d3 <- d2
for (i in c("Mar","Apr","May","Sep")) {
d3 <- rbind(d3,NA)
d3$month[nrow(d3)] <- i
d3$temp[nrow(d3)] <- 0
}
plot(temp ~ month, d3) # still ugly, but at least has 12 months!
## Section 3: Solution
The obvious solution is to leave a blank where a boxplot should go,
similar to tapply. This would have 1:n positions, where n is the
number of levels of the factor, not the number of factors that have
one or more numbers. The position should also have a label under the
tick mark.
I don't see any reason why the missing data should be completely
ignored. Users wishing to not plot the blanks where the data could go
can simply type (for back-compatibility):
d2$month <- factor(d2$month) # from 12 to 8 levels
Which will produce the same 8-factor plot as above.
## Section 4: Conclusion
I consider this to be a bug in regards to data representation, and
this function is not consistant with other functions like `tapply'.
Considering that the back-compatibility solution is very simple, and
most users would probably prefer a result including all levels (NULL
or real values in each), I feel this an appropriate improvement (and
easy to fix in the code). At the very least, include an option to
honour the factor levels.
Thanks.
-mt
--please do not edit the information below--
Version:
platform = powerpc-apple-darwin8.1.0
arch = powerpc
os = darwin8.1.0
system = powerpc, darwin8.1.0
status = Patched
major = 2
minor = 1.1
year = 2005
month = 06
day = 26
language = R
Locale:
en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
Search Path:
.GlobalEnv, package:methods, package:stats, package:graphics,
package:grDevices, package:utils, package:datasets, Autoloads,
package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] capabilities() and non-catchable messages
Prof Brian Ripley wrote:
> Do you have DISPLAY set pointing to an X11 server you do not have
> access to? It seems so. The solution is to set your X11 settings
> properly.
>
> This is coming from Xlib (XOpenDisplay, I believe) and so is not an R
> error or warning, and is not output on an R connection but on a C file.
Another clear answer/hint! The sysadms of the host system just got back
to me and said that they set the DISPLAY on purpose in order to generate
bitmap graphics in R using X11. The thing was that during the few days
when I was testing my plugin, the X11 server was unreachable due to DNS
problems after a power failure. There is always a simple answer ;)
Thanks
Henrik
> On Mon, 20 Jun 2005, Henrik Bengtsson wrote:
>
>
>>Just for the record (not a request for fix) and an ad hoc workaround if
>>anyone needs it:
>>
>>REASON:
>>Running an R script as a plugin on a remote Suse Linux 8.2 with R v2.1.0
>>(2005-04-18), I have noticed that capabilities() generates (to standard
>>error)
>>
>> Xlib: connection to "base:0.0" refused by server
>> Xlib: Client is not authorized to connect to Server
>>
>>which cannot be caught by tryCatch();
>>
>> tryCatch({
>>print(capabilities());
>> }, condition=function(c) {
>>cat("Condition caught:\n");
>>str(c);
>> })
>>
>>because it is not a 'condition' (error or warning).
>>
>>CONTEXT:
>>Since source() calls capabilities("iconv") this messages always show up.
>>My R plugin loads custom code using source() and since the standard
>>error from the plugin is checked for messages, the host system
>>interprets this as if something problematic has occured.
>>
>>WORKAROUND:
>>The workaround that I use now is to redefine capabilities() temporarily
>>(since I do not need "iconv" support):
>>
>> orgCapabilities <- base::capabilities;
>> basePos <- which(search() == "package:base"));
>> assign("capabilities", function(...) FALSE, pos=basePos);
>>
>> source()
>>
>> basePos <- which(search() == "package:base"));
>> assign("capabilities", orgCapabilities, pos=basePos);
>> rm(orgCapabilities)
>>
>>Cheers
>>
>>Henrik
>>
>>__
>>R-devel@r-project.org mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in compiling R
When compiling R on Windows, I am getting the following error. Does anyone have any suggestions? -- Making package datasets adding build stamp to DESCRIPTION installing R files installing data files preparing package datasets for lazy data loading Error in load(zfile, envir = envir) : input has been corrupted, with LF replaced by CR Execution halted make[4]: *** [lazydata] Error 1 make[3]: *** [all] Error 2 make[2]: *** [pkg-datasets] Error 2 make[1]: *** [rpackage] Error 1 make: *** [all] Error 2 Thanks, Chad Jenness Electronic Payment Business Services Office: 612-667-9782 Email: [EMAIL PROTECTED] "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation" [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot by factor (Package base version 2.1.1) ( PR#7976)
The issue is not with boxplot, but with split. boxplot.formula()
calls boxplot(split(split(mf[[response]], mf[-response]), ...),
but look at what split() returns when there are empty levels in
the factor:
> f <- factor(gl(3, 6), levels=1:5)
> y <- rnorm(f)
> split(y, f)
$"1"
[1] 0.4832124 1.1924811 0.3657797 1.7400198 0.5577356 0.9889520
$"2"
[1] -1.1296642 -0.4808355 -0.2789933 0.1220718 0.1287742 -0.7573801
$"3"
[1] 1.2320902 0.5090700 -1.5508074 2.1373780 1.1681297 -0.7151561
The "culprit" is the following in split.default():
f <- factor(f)
which drops empty levels in f, if there are any. BTW, ?split doesn't
mention what it does in such situation. Perhaps it should?
If this is to be "fixed", I suppose an additional argument, e.g.,
drop=TRUE, can be added, and the corresponding line mentioned
above changed to something like:
if (drop || !is.factor(f)) f <- factor(f)
Then this additional argument can be pass on from boxplot.formula() to
split().
Just my $0.02...
Andy
> From: [EMAIL PROTECTED]
>
> I consider this to be an old bug, which also persists in Splus 7. It
> is unnecessary, and annoying.
>
> ## Section 1: Consider a simple data frame with three possible
> factors (in levels)
>
> d <- data.frame(a=sort(rnorm(10)*10), b=factor(c(rep("A",4), rep("C",
> 6)), levels=c("A","B","C")))
> tapply(d$a, d$b, mean) # returns three results, which I would expect
> plot(a ~ b, d) # plots only two of three objects, ignoring
> that there
> was "C" in the second position
>
> # if I tried to plot a blank in between the two boxplots:
> plot(a ~ b, d, at=1:3) # nope: error
> plot(a ~ b, d, at=c(1,3)) # nope: out of range (also xlim does
> nothing for the formula boxplot method)
>
> # to make this work with the current R/Splus implementation, I have
> to add a zero:
> d <- rbind(d, data.frame(a=0,b="B")) # which I don't want to do,
> since there are no "B"
> plot(a ~ b, d) # yuk!
>
> ## Section 2: Why is this important? Consider another realistic
> example of [synthetic] daily temperature
>
> temp <- 5 - 10*cos(1:365*2*pi/365) + rnorm(365)*3
> d1 <- data.frame(year=2005, jday=1:365, date=NA, month=NA, temp) #
> jday is Julian day [1,365]
> d1$date <- as.Date(paste(d1$year, d1$jday), "%Y %j")
> d1$month <- factor(months(d1$date,TRUE), levels=month.abb)
> plot(temp ~ month, d1) # perfect, in a perfect meteorological world
>
> d2 <- d1[!d1$month %in% c("Mar","Apr","May","Sep"),] # now let's
> remove some data
> tapply(d2$temp,d2$month,mean) # perfect
> plot(temp ~ month, d2) # ugly, not 12 months, etc. (despite
> having 12
> levels)
>
> # again the only cure is to add zeros to the missing months
> (unnecessary forgery of data)
> d3 <- d2
> for (i in c("Mar","Apr","May","Sep")) {
> d3 <- rbind(d3,NA)
> d3$month[nrow(d3)] <- i
> d3$temp[nrow(d3)] <- 0
> }
> plot(temp ~ month, d3) # still ugly, but at least has 12 months!
>
> ## Section 3: Solution
> The obvious solution is to leave a blank where a boxplot should go,
> similar to tapply. This would have 1:n positions, where n is the
> number of levels of the factor, not the number of factors that have
> one or more numbers. The position should also have a label
> under the
> tick mark.
> I don't see any reason why the missing data should be completely
> ignored. Users wishing to not plot the blanks where the data
> could go
> can simply type (for back-compatibility):
>
> d2$month <- factor(d2$month) # from 12 to 8 levels
>
> Which will produce the same 8-factor plot as above.
>
> ## Section 4: Conclusion
> I consider this to be a bug in regards to data representation, and
> this function is not consistant with other functions like `tapply'.
> Considering that the back-compatibility solution is very simple, and
> most users would probably prefer a result including all levels (NULL
> or real values in each), I feel this an appropriate improvement (and
> easy to fix in the code). At the very least, include an option to
> honour the factor levels.
>
> Thanks.
> -mt
>
> --please do not edit the information below--
>
> Version:
> platform = powerpc-apple-darwin8.1.0
> arch = powerpc
> os = darwin8.1.0
> system = powerpc, darwin8.1.0
> status = Patched
> major = 2
> minor = 1.1
> year = 2005
> month = 06
> day = 26
> language = R
>
> Locale:
> en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
>
> Search Path:
> .GlobalEnv, package:methods, package:stats, package:graphics,
> package:grDevices, package:utils, package:datasets, Autoloads,
> package:base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in compiling R
On Tue, 28 Jun 2005 [EMAIL PROTECTED] wrote: > When compiling R on Windows, I am getting the following error. Does > anyone have any suggestions? Yes, it seems you have corrupted the files during unpacking. Did you use the version of tar in the Rtools.zip? Whatever you used to unpack the files has changed LF to CR line endings. Winzip is notorious for doing things like that. Only a very few tools will unpack that tar file (which contains symbolic links) correctly. Which is why we provide one, and issue a warning in the R Installation and Administration manual. > -- Making package datasets > adding build stamp to DESCRIPTION > installing R files > installing data files > preparing package datasets for lazy data loading > Error in load(zfile, envir = envir) : input has been corrupted, with LF > replaced > by CR > Execution halted > make[4]: *** [lazydata] Error 1 > make[3]: *** [all] Error 2 > make[2]: *** [pkg-datasets] Error 2 > make[1]: *** [rpackage] Error 1 > make: *** [all] Error 2 > > > Thanks, > Chad Jenness > Electronic Payment Business Services > Office: 612-667-9782 > Email: [EMAIL PROTECTED] > > "This message may contain confidential and/or privileged information. > If you are not the addressee or authorized to receive this for the > addressee, you must not use, copy, disclose, or take any action based on > this message or any information herein. If you have received this > message in error, please advise the sender immediately by reply e-mail > and delete this message. Thank you for your cooperation" > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot by factor (Package base version 2.1.1) ( PR#7976)
"Liaw, Andy" <[EMAIL PROTECTED]> writes: > The issue is not with boxplot, but with split. boxplot.formula() > calls boxplot(split(split(mf[[response]], mf[-response]), ...), > but look at what split() returns when there are empty levels in > the factor: > > > f <- factor(gl(3, 6), levels=1:5) > > y <- rnorm(f) > > split(y, f) > $"1" > [1] 0.4832124 1.1924811 0.3657797 1.7400198 0.5577356 0.9889520 > > $"2" > [1] -1.1296642 -0.4808355 -0.2789933 0.1220718 0.1287742 -0.7573801 > > $"3" > [1] 1.2320902 0.5090700 -1.5508074 2.1373780 1.1681297 -0.7151561 > > The "culprit" is the following in split.default(): > > f <- factor(f) > > which drops empty levels in f, if there are any. BTW, ?split doesn't > mention what it does in such situation. Perhaps it should? > > If this is to be "fixed", I suppose an additional argument, e.g., > drop=TRUE, can be added, and the corresponding line mentioned > above changed to something like: > > if (drop || !is.factor(f)) f <- factor(f) > > Then this additional argument can be pass on from boxplot.formula() to > split(). Alternatively, I suspect that the intention was as.factor() rather than factor(). It does require a bit of care to fix it that way, though. There could be problems with empty levels popping up in unexpected places. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in compiling R
Thanks, I got this resolved. Now to embed the R.dll into a C application, do I need to compile R with any shared library flags set? Chad Jenness Electronic Payment Business Services Office: 612-667-9782 Email: [EMAIL PROTECTED] "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation" -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 28, 2005 7:47 AM To: [EMAIL PROTECTED] Cc: r-devel@r-project.org Subject: Re: [Rd] Error in compiling R On Tue, 28 Jun 2005 [EMAIL PROTECTED] wrote: > When compiling R on Windows, I am getting the following error. Does > anyone have any suggestions? Yes, it seems you have corrupted the files during unpacking. Did you use the version of tar in the Rtools.zip? Whatever you used to unpack the files has changed LF to CR line endings. Winzip is notorious for doing things like that. Only a very few tools will unpack that tar file (which contains symbolic links) correctly. Which is why we provide one, and issue a warning in the R Installation and Administration manual. > -- Making package datasets > adding build stamp to DESCRIPTION > installing R files > installing data files > preparing package datasets for lazy data loading > Error in load(zfile, envir = envir) : input has been corrupted, with > LF replaced by CR > Execution halted > make[4]: *** [lazydata] Error 1 > make[3]: *** [all] Error 2 > make[2]: *** [pkg-datasets] Error 2 > make[1]: *** [rpackage] Error 1 > make: *** [all] Error 2 > > > Thanks, > Chad Jenness > Electronic Payment Business Services > Office: 612-667-9782 > Email: [EMAIL PROTECTED] > > "This message may contain confidential and/or privileged information. > If you are not the addressee or authorized to receive this for the > addressee, you must not use, copy, disclose, or take any action based > on this message or any information herein. If you have received this > message in error, please advise the sender immediately by reply e-mail > and delete this message. Thank you for your cooperation" > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Does not run under Mac OS X 10.3.9 (PR#7975)
You should give us more feedback if you want us to be of any help to you. Could you please send us the crash report of R? (See Console.app in / Applications/Utilities ) stefano On 28/giu/05, at 06:23, [EMAIL PROTECTED] wrote: > Full_Name: Matthias Wahl > Version: 2.0.1 and 2.1.0a > OS: Mac OS X 10.3.9 > Submission from: (NULL) (84.159.39.159) > > > Version 2.1.0a does get installed, R is available under applications, > however when trying to start R I get an error message that R is > terminated > due to an error and that's it. Re-installing didn't help at all. > > Then I tried Version 2.0.1. and there I don't even get an icon to > start R. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot by factor (Package base version 2.1.1) ( PR#7976)
Based on Andy's comment a workaround can consist of
not using boxplot.formula, e.g. using the data frame d
defined by the original poster (see below):
boxplot( by(d, d$b, function(x)x$a) )
On 6/28/05, Liaw, Andy <[EMAIL PROTECTED]> wrote:
> The issue is not with boxplot, but with split. boxplot.formula()
> calls boxplot(split(split(mf[[response]], mf[-response]), ...),
> but look at what split() returns when there are empty levels in
> the factor:
>
> > f <- factor(gl(3, 6), levels=1:5)
> > y <- rnorm(f)
> > split(y, f)
> $"1"
> [1] 0.4832124 1.1924811 0.3657797 1.7400198 0.5577356 0.9889520
>
> $"2"
> [1] -1.1296642 -0.4808355 -0.2789933 0.1220718 0.1287742 -0.7573801
>
> $"3"
> [1] 1.2320902 0.5090700 -1.5508074 2.1373780 1.1681297 -0.7151561
>
> The "culprit" is the following in split.default():
>
>f <- factor(f)
>
> which drops empty levels in f, if there are any. BTW, ?split doesn't
> mention what it does in such situation. Perhaps it should?
>
> If this is to be "fixed", I suppose an additional argument, e.g.,
> drop=TRUE, can be added, and the corresponding line mentioned
> above changed to something like:
>
>if (drop || !is.factor(f)) f <- factor(f)
>
> Then this additional argument can be pass on from boxplot.formula() to
> split().
>
> Just my $0.02...
>
> Andy
>
> > From: [EMAIL PROTECTED]
> >
> > I consider this to be an old bug, which also persists in Splus 7. It
> > is unnecessary, and annoying.
> >
> > ## Section 1: Consider a simple data frame with three possible
> > factors (in levels)
> >
> > d <- data.frame(a=sort(rnorm(10)*10), b=factor(c(rep("A",4), rep("C",
> > 6)), levels=c("A","B","C")))
> > tapply(d$a, d$b, mean) # returns three results, which I would expect
> > plot(a ~ b, d) # plots only two of three objects, ignoring
> > that there
> > was "C" in the second position
> >
> > # if I tried to plot a blank in between the two boxplots:
> > plot(a ~ b, d, at=1:3) # nope: error
> > plot(a ~ b, d, at=c(1,3)) # nope: out of range (also xlim does
> > nothing for the formula boxplot method)
> >
> > # to make this work with the current R/Splus implementation, I have
> > to add a zero:
> > d <- rbind(d, data.frame(a=0,b="B")) # which I don't want to do,
> > since there are no "B"
> > plot(a ~ b, d) # yuk!
> >
> > ## Section 2: Why is this important? Consider another realistic
> > example of [synthetic] daily temperature
> >
> > temp <- 5 - 10*cos(1:365*2*pi/365) + rnorm(365)*3
> > d1 <- data.frame(year=2005, jday=1:365, date=NA, month=NA, temp) #
> > jday is Julian day [1,365]
> > d1$date <- as.Date(paste(d1$year, d1$jday), "%Y %j")
> > d1$month <- factor(months(d1$date,TRUE), levels=month.abb)
> > plot(temp ~ month, d1) # perfect, in a perfect meteorological world
> >
> > d2 <- d1[!d1$month %in% c("Mar","Apr","May","Sep"),] # now let's
> > remove some data
> > tapply(d2$temp,d2$month,mean) # perfect
> > plot(temp ~ month, d2) # ugly, not 12 months, etc. (despite
> > having 12
> > levels)
> >
> > # again the only cure is to add zeros to the missing months
> > (unnecessary forgery of data)
> > d3 <- d2
> > for (i in c("Mar","Apr","May","Sep")) {
> > d3 <- rbind(d3,NA)
> > d3$month[nrow(d3)] <- i
> > d3$temp[nrow(d3)] <- 0
> > }
> > plot(temp ~ month, d3) # still ugly, but at least has 12 months!
> >
> > ## Section 3: Solution
> > The obvious solution is to leave a blank where a boxplot should go,
> > similar to tapply. This would have 1:n positions, where n is the
> > number of levels of the factor, not the number of factors that have
> > one or more numbers. The position should also have a label
> > under the
> > tick mark.
> > I don't see any reason why the missing data should be completely
> > ignored. Users wishing to not plot the blanks where the data
> > could go
> > can simply type (for back-compatibility):
> >
> > d2$month <- factor(d2$month) # from 12 to 8 levels
> >
> > Which will produce the same 8-factor plot as above.
> >
> > ## Section 4: Conclusion
> > I consider this to be a bug in regards to data representation, and
> > this function is not consistant with other functions like `tapply'.
> > Considering that the back-compatibility solution is very simple, and
> > most users would probably prefer a result including all levels (NULL
> > or real values in each), I feel this an appropriate improvement (and
> > easy to fix in the code). At the very least, include an option to
> > honour the factor levels.
> >
> > Thanks.
> > -mt
> >
> > --please do not edit the information below--
> >
> > Version:
> > platform = powerpc-apple-darwin8.1.0
> > arch = powerpc
> > os = darwin8.1.0
> > system = powerpc, darwin8.1.0
> > status = Patched
> > major = 2
> > minor = 1.1
> > year = 2005
> > month = 06
> > day = 26
> > language = R
> >
> > Locale:
> > en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
> >
> > Search Path:
> > .GlobalEnv, package:methods, package:stats, package:graphics,
> > package:grDevices, package:utils, pa
Re: [Rd] Error in compiling R
On Tue, 28 Jun 2005 [EMAIL PROTECTED] wrote: > Thanks, I got this resolved. Now to embed the R.dll into a C > application, do I need to compile R with any shared library flags set? Not for Windows, but all the details are in the `Writing R Extensions' manual. You proabably don't want to use R.dll directly (but you can) but rather via COM. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Running ./tools/rsync-recommended through a proxy
My computers at my office will no longer be able to connect directly to web sites etc. I will be going through a proxy server. The particular server is running squid on port 3128. I have managed to configure web browsers, ssh, apt, svn and a whole lot of other tools to use the proxy server but I haven't been able to configure rsync. My usual method of updating my copy of the R-devel sources is via cd my_R_devel_sources svn up ./tools/rsync-recommended cd my_R_build_directory ... Can anyone offer suggestions on how to get rsync-recommended to work through a proxy? I have set export RSYNC_PROXY="machine.name:3128" which I understand from the documentation is the magic environment variable (I don't give the name of the server explicitly because it is an open proxy). However, I still get [EMAIL PROTECTED]:/usr/src/r-devel$ ./tools/rsync-recommended bad response from proxy - HTTP/1.0 403 Forbidden rsync: failed to connect to machine.name: Success (0) rsync error: error in socket IO (code 10) at clientserver.c(94) *** rsync failed to update Recommended files *** Creating links Is it likely that the proxy server is not passing connections to port 873? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
