[Rd] Project suggestion: Interface between R and graphic devices
Hi to all developer, sure that I will not be the first one with this idea but I did not found treads about this. I realized that there are some user interfaces like Brodgar and SciViews. There was used a lot of manpower to develop those programs. On the other side I realized that it could be very helpful to have such programs if somebody would like to change the statistical software from SPSS or other commercial software to R-Statistic. The first steps would be more easy and the acceptance of R would be much more than with the command line interpreter. It would be a great help to introduce R in the institutes, which does not use R just now. One of the features of R is that it is state of the art all the time. If anybody would use R version 1.?? because of any graphic devise it would not be helpful. So my suggestion: Is it possible to define any interface between the R-system and the Gui applications, so that the GUIs, but only the interface does need to rebuild if the R-system is changed. I am out of order with programming since ten years, but it seems (but it not sure just now) that I have more time to oversee such a project. But I will need a lot of advice the first time. I was developing the software for medical systems and this would be a complete new subject for me. with regards Knut Krueger http://www.biostatistic.de __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Project suggestion: Interface between R and graphic devices
I think you do not mean `graphics devices' as used by R (pdf, postscript, X11, windows, quartz etc). Rather I think you mean interfacing to a different front end. That is a subject discussed in `Writing R Extensions' and an API for it has been defined for a few R versions now. The JGR and MacGUI front ends are examples of what can be done, and gnoneGUI is a reference example. There is a mailing list (R-SIG-GUI) and an overview page at http://www.sciviews.org/_rgui/ (I noted that JGR for Windows seems to need updating to work on 2.2.0: it demands 2.1.x.) Rcmdr is a powerful example of how a cross-platform GUI can be built entirely in R. In particular, my understanding is that it is specifically designed to ease the transition from SPSS to R. Given that background, what more precisely do you think is needed and would not the R-SIG-GUI list be more appropriate? On Sun, 9 Oct 2005, Knut Krueger wrote: > Hi to all developer, > sure that I will not be the first one with this idea but I did not found > treads about this. > I realized that there are some user interfaces like Brodgar and SciViews. > There was used a lot of manpower to develop those programs. > On the other side I realized that it could be very helpful to have such > programs if somebody would like to change the statistical software from > SPSS or other commercial software to R-Statistic. The first steps would > be more easy and the acceptance of R would be much more than with the > command line interpreter. > It would be a great help to introduce R in the institutes, which does > not use R just now. > One of the features of R is that it is state of the art all the time. If > anybody would use R version 1.?? because of any graphic devise it would > not be helpful. > > So my suggestion: > Is it possible to define any interface between the R-system and the Gui > applications, so that the GUIs, but only the interface does need to > rebuild if the R-system is changed. > > I am out of order with programming since ten years, but it seems (but it > not sure just now) that I have more time to oversee such a project. But > I will need a lot of advice the first time. > I was developing the software for medical systems and this would be a > complete new subject for me. > > with regards > Knut Krueger > http://www.biostatistic.de > > __ > 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] Project suggestion: Interface between R and graphic devices
Prof Brian Ripley schrieb: > I think you do not mean `graphics devices' as used by R (pdf, > postscript, X11, windows, quartz etc). Sorry no I do not mean such "devices" I thought about the Graphic User Interfaces, to use the R-System with a windows like surface http://www.sciviews.org/. I see the difficulties for the user which want to change from SPSS or Statistica or ? to R just inside my family. I am using R to reproduce the SPSS results (just for fun because I want my to learn R) my wife is using SPSS for her research program. But it takes a long time for scientist to learn the command line syntax. There is not time for this if the scientist is just inside a any research ... and the scientist is mostly inside any research. for example http://www.sciviews.org/. was broken since the new version 2.?? (I think so). But if there would be a defined interface between the GUIs and R the developer of this interface must only change one interface instead all developer of the GUIs must change their GUIs If i remember then I it was a great improvement of Linux in the past after there was a GUI available which was like windows. This was a great step for the acceptance of LINUX. I think this would be the same for R. but there must be a stable interface for GUI programmers available before. Hope this could clarify my suggestion :-) Regards Knut __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Project suggestion: Interface between R and graphic devices
> > > Prof Brian Ripley wrote: > Please so read the part of my message that you have silently deleted > here. > > There IS A STABLE API, as I said there. What could be the problem for the developer of the GUIs. One of the Gui is only working with a 1.4? version, one of the GUI is only working with the lower than 2.0. and so on. Don't they use the API or is the API not suitable for them? Regards Knut __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Project suggestion: Interface between R and graphic devices
Knut Krueger wrote: > > Prof Brian Ripley schrieb: > > >>I think you do not mean `graphics devices' as used by R (pdf, >>postscript, X11, windows, quartz etc). > > > Sorry no I do not mean such "devices" > I thought about the Graphic User Interfaces, to use the R-System with a > windows like surface http://www.sciviews.org/. > I see the difficulties for the user which want to change from SPSS or > Statistica or ? to R just inside my family. > I am using R to reproduce the SPSS results (just for fun because I want > my to learn R) my wife is using SPSS for her research program. > But it takes a long time for scientist to learn the command line syntax. > There is not time for this if the scientist is just inside a any > research ... and the scientist is mostly inside any research. > > for example http://www.sciviews.org/. was broken since the new version > 2.?? (I think so). But if there would be a defined interface between the > GUIs and R the developer of this interface must only change one > interface instead all developer of the GUIs must change their GUIs > If i remember then I it was a great improvement of Linux in the past > after there was a GUI available which was like windows. This was a great > step for the acceptance of LINUX. I think this would be the same for R. > but there must be a stable interface for GUI programmers available before. > Hope this could clarify my suggestion :-) > > Regards Knut This is not true. Version 0.8-8 of SciViews-R (http://www.sciviews.org/SciViews-R) is compatible with R 2.1.1. There were several months of delay between R 2.1.X and the compatible SciViews-R version... There were a lot of changes required in my code, because of the internationalization of R. I though translating R in French was a priority, so, I have been working on "R French" first. Also, I took a little time with my baby that was born in April... life is not limited to programming R! Remember that Open Source is a collaborative and voluntary approach of developing software. If you want to use all the time the latest R version, just learn to use its standard command line interface. If you prefer SciViews, JGR, R Commander, etc., then you should expect some delay before R releases and compatible GUI releases. Indeed, one must say that R Commander has always been released on time with the latest R version, as fart as I know, and JGR is very close to. Latest SciViews version was very, very late. I apologize for that. Best regards, Philippe Grosjean ..<°}))>< ) ) ) ) ) ( ( ( ( (Prof. Philippe Grosjean ) ) ) ) ) ( ( ( ( (Numerical Ecology of Aquatic Systems ) ) ) ) ) Mons-Hainaut University, Pentagone (3D08) ( ( ( ( (Academie Universitaire Wallonie-Bruxelles ) ) ) ) ) 8, av du Champ de Mars, 7000 Mons, Belgium ( ( ( ( ( ) ) ) ) ) phone: + 32.65.37.34.97, fax: + 32.65.37.30.54 ( ( ( ( (email: [EMAIL PROTECTED] ) ) ) ) ) ( ( ( ( (web: http://www.umh.ac.be/~econum ) ) ) ) ) http://www.sciviews.org ( ( ( ( ( .. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] all.equal() improvements (PR#8191)
--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
The attached patch against R 2.2.0 makes the following improvements to
the all.equal() function:
1. Check names! Stock R all.equal() (unlike S-Plus) ignores names
completely on some objects. I consider this wrong - if the names
are different, the object is NOT "the same".
2. When a difference is detected, return better output to help the
user understand just WHAT is different.
Further details are included in the code comments, but in particular,
all.equal.list() is much enhanced. By default it still checks list
values by postion rather than name, as that behavior is more strict
and thus more correct.
But when using the by.name="auto" and by.pos=TRUE options (which are
the defaults), in addition to by-positing differences,
all.equal.list() now also reports by-name differences in those places
(and only those places) where doing so should be helpful to the user.
Also, optionally, using by.name=TRUE and by.pos=FALSE will give
behavior like S-Plus.
The attached patch is also available here:
http://www.piskorski.com/R/patches/all-equal-patch-20051009.txt
If you want to see the entire file rather than a patch against R
2.2.0, that is also available here:
http://www.piskorski.com/R/patches/all.equal.R
--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com/
--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="all-equal-patch-20051009.txt"
Index: all.equal.R
===
RCS file: /home/cvsroot/dtk/Splus/patches/all.equal.R,v
retrieving revision 1.1.1.1
retrieving revision 1.4
diff -u -r1.1.1.1 -r1.4
--- all.equal.R 1 Oct 2005 06:51:06 - 1.1.1.1
+++ all.equal.R 1 Oct 2005 13:10:25 - 1.4
@@ -1,4 +1,75 @@
-all.equal <- function(target, current, ...) UseMethod("all.equal")
+#
+# This is a copy of "src/library/base/R/all.equal.R" from
+# "R-beta_2005-09-24_r35666.tar.gz", plus our modifications. (The
+# all.equal.R in that tarball seems to be unchanged at least as far
+# back as R 2.1.0.)
+#
+# Further detail is in the comments in each function, but basically,
+# all modifications here involve either of two sorts of improvements:
+#
+# 1. Check names! Stock R all.equal() (unlike S-Plus) ignores names
+#completely on some objects. I consider this bogus, if the names
+#are different, the object is NOT "the same".
+#
+# 2. When the object is different, return more output to help the user
+#understand just WHAT is different.
+#
+# Note: Here in our patches package, we purposely CVS import and than
+# override ALL the base all.equal() methods, NOT just the ones we're
+# actually modifying. At first I tried only overriding some of them,
+# but in that case, even though package:patches was earlier on the
+# search path than package:base, base methods appeared to
+# preferentially call the original base versions, rather than the
+# patches versions that I wanted. So, big hammer it, override
+# everything - which will probably make it easier to contribute these
+# improvements back to stock R anyway.
+#
+# [EMAIL PROTECTED], 2005/10/01 02:29 EDT
+#
+# $Id: all.equal.R,v 1.4 2005/10/01 13:10:25 andy Exp $
+
+
+# In S-Plus, all.equal() prefers to index objects by name, while in
+# stock R, it prefers to index by position. IMO, *NEITHER* of those
+# behaviors are fully correct. What we really want is to compare
+# things BOTH by name and by position.
+#
+# Here's ONE example of the effect of these R patches:
+#
+## S-Plus 6.2, no patches to all.equal():
+#> all.equal(list(a=2,2,x=3,zap=1,foo=42,"NA"=T)
,list(b=1,2,y=4,foo=7,zap=1,"NA"=F))
+#[1] "Names: 4 string mismatches"
+#[2] "Components not in target: b, y"
+#[3] "Components not in current: a, x"
+#[4] "Component foo: Mean relative difference: 0.833"
+#[5] "Component NA: Mean relative difference: 1"
+#
+## R 2.1.0, no patches to all.equal():
+#> all.equal(list(a=2,2,x=3,zap=1,foo=42,"NA"=T)
,list(b=1,2,y=4,foo=7,zap=1,"NA"=F))
+#[1] "Names: 4 string mismatches"
+#[2] "Component 1: Mean relative difference: 0.5"
+#[3] "Component 3: Mean relative difference: 0.333"
+#[4] "Component 4: Mean relative difference: 6"
+#[5] "Component 5: Mean relative difference: 0.9761905"
+#[6] "Component 6: Mean relative difference: 1"
+#
+## R 2.1.0 with our patches here:
+#> all.equal(list(a=2,2,x=3,zap=1,foo=42,"NA"=T)
,list(b=1,2,y=4,foo=7,zap=1,"NA"=F))
+# [1] "Names: 4 string mismatches"
Re: [Rd] Project suggestion: Interface between R and graphic devices
Philippe Grosjean schrieb:
>
> This is not true. Version 0.8-8 of SciViews-R
> (http://www.sciviews.org/SciViews-R) is compatible with R 2.1.1. There
> were several months of delay between R 2.1.X and the compatible
> SciViews-R version... There were a lot of changes required in my code,
> because of the internationalization of R. I though translating R in
> French was a priority, so, I have been working on "R French" first.
> Also, I took a little time with my baby that was born in April... life
> is not limited to programming R!
Congratulations I know the time when my boy was born.
>
> Remember that Open Source is a collaborative and voluntary approach of
> developing software.
Please don't misunderstand my question.
We developed a couple of (commercial) programs for medical university use.
On of the required things were compatible interfaces between different
hardware and software parts.
for example:
There was a definition of a function call:
function (Var1, Var2, ., Version)
begin
case version of
version1: ...
version2 ...
end {case}
end {function}
This functions and procedures did the communication between different
versions of hard an software.
And the open source community is the best development environment to
develop and take care for such API.
So back to my suggestion.
You told me that you must do a lot of changes in your GUI. If there
would be one API which is serving a couple of old R Versions, then all
running systems of GUIs would be running even the code for the latest
R-version is changed. And only one part of the code must be changed not
all available GUIs.
> If you want to use all the time the latest R version, just learn to
> use its standard command line interface.
Some of the user want to use the newest command line interface some of
(the newbies) want to use GUIs
> If you prefer SciViews, JGR, R Commander, etc., then you should expect
> some delay before R releases and compatible GUI releases. Indeed, one
> must say that R Commander has always been released on time with the
> latest R version, as fart as I know, and JGR is very close to.
and this is the point that I thought maybe there could be some
improvement with an universal API for GUIs
> Latest SciViews version was very, very late. I apologize for that.
Please don't think that this was my intention - it was just the other
side. I realized that there was a long time especially for your nice GUI
and I thought:
It seems to be wasted time if Mr Grosjean must always do such a lot work
after there is a new version of R. And therefor I tough about something
to do for the R-Community.
But dear community please see this suggestion in a manner that I do not
have any knowledge about the work of the core team but that I am
fascinated about the work, but that I am not able to win user for R
because of problems with missing or not working GUIs.
Missing:
I do not know whether you know Wordperfect Office. They want the user to
change from MS-Office.
They build in a function: Switch to Word Mode, or switch to Powerpoint
Mode. and this is the point to get Statistica user and SPSS user away
from their programs.
medium universities in Germany have between 500 and 1000 licences for
SPSS. What a lot of money which is not available for the researchers
Conclusion.
I did not want a just ready solution, but I thought about some steps for
the next years.
There is an API available if I understand Prof. Ripley right, but then I
do not understand the problems of the GUI developer.
And please again I do not want to blame anybody of any development team
I want to understand the project.
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Project suggestion: Interface between R and graphic devices
Knut, On Oct 9, 2005, at 1:19 PM, Knut Krueger wrote: >> If you prefer SciViews, JGR, R Commander, etc., then you should >> expect >> some delay before R releases and compatible GUI releases. Indeed, one >> must say that R Commander has always been released on time with the >> latest R version, as fart as I know, and JGR is very close to. >> > > and this is the point that I thought maybe there could be some > improvement with an universal API for GUIs As Brian was pointing out there is such an API and as with all APIs it is allowed to improve between releases. All projects allow this including unix UI projects you mentioned. In most cases the update of the GUI for a next R version consists of re-compiling the GUI, that's all. Again, this is always necessary, independent of the API, for various reasons (some of them platform-dependent such as that with new R version the location of the R dynamic library may have changed). The API changes usually add new functionality and hence new possibilities. As Philippe was saying, the delays are then not because of API changes, but because the GUI authors want to take advantage of that new functionality. (In the last 6 releases of R I remember only two restructuring changes in the API, both taking less than 5 lines of code to adapt to - modulo graphics devices, of course). I didn't check all the GUIs, but for JGR I can say that you can get it immediately at the time of R release if you compile it from sources. From my point of view I can say that building and testing of installers and binaries takes far more time than fixing the code for API changes. If you are willing to build and test binaries during the R beta phase, you're encouraged to do so - that would make the GUI available right on time for the R release. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [ subscripting sometimes loses names (PR#8192)
--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
R, like recent versions of S-Plus, sometimes - but not always - loses
names when subscripting objects with "[". (Earlier versions of S and
S-Plus had the correct, name-preserving behavior.) This seems bad, it
would be better to remove names only by explicit request, not as an
accidental side-effect of some (but not all) subscripting operations.
This issue was also discusses back in 2001 on the S-News list:
http://www.biostat.wustl.edu/archives/html/s-news/2001-09/msg00020.html
The attached file, "fix-names.s", is also available here:
http://www.piskorski.com/R/patches/fix-names.s
It includes:
1. The function dtk.test.brace.names(), which demonstrates name losing
problem, and can automatically report which test cases pass/fail, etc.
2. Wrappers for the "[" and "[.data.frame" functions which fix the
losing names problem for all the cases I've tried.
Note that dtk.test.brace.names(T) will always run all its test cases
and return their output for human inspection. However, its checks to
see whether each test passes or fails only work correctly with the
patched all.equal() in PR#8191.
My coworkers and I have been using these wrapper functions for ALL
code we run for many months now, with no problems so far. However,
there are probably some cases we don't use, like objects with S4
classes, which don't work right with these wrappers.
I assume the R core team would NOT want to use these wrapper
functions, but would instead prefer to change the underlying code
directly. However, I offer them as an example of one way to achieve
what we believe to be the correct name-preserving behavior in R.
I would appreciate any suggestions on how to better implement this
name-preserving behavior for all R subscripting operations.
--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com/
--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="fix-names.s"
dtk.null <- function(...) {}
#
# Fix loss of dimnames when subcripting with "[":
#
# According to Gary Sabot <[EMAIL PROTECTED]>, S-Plus originally had the
# correct name-preserving behavior we want. Then in 1996 Insightful
# broke that in Splus 3.4, which Gary fixed for his own use. In 2001,
# Splus 6.0 broke something in Gary's fix, he posted questions to the
# s-news list, generating discussion, including some shock that anyone
# could think that arbitrarily losing dimnames made sense:
#
# http://www.biostat.wustl.edu/archives/html/s-news/2001-09/msg00020.html
#
# Unfortunately R seems to mimic much of the more recent buggy S-Plus
# behavior! Thus our patches to both S-Plus and R below. To test
# that they do the right thing, run dtk.test.brace.names().
#
# Note that currently these patches wrap the stock subscripting
# functions, they do NOT replace them. TODO: Investigate fixing the
# stock implementation instead, especially for R.
#
# [EMAIL PROTECTED], 2005/09/27 17:03 EDT
#
if (!.R.) { # For S-Plus:
# First make sure that if you run this twice, you still get the
# real original function:
data.frame.original.fcn <- get("[.data.frame", where="splus")
# For S-Plus (at least version 6.2.1) we do not need to override
# the "[" function, it already does the right thing.
# [EMAIL PROTECTED], 2005/07/01 10:11 EDT
"[.data.frame" <- function(x ,... ,drop=T) {
# TODO: Problem: New lm() is dying with my patch, because it indexes
something
# and produces something that looks like it has 2 cols, but ncol returns
1.
# I can detect/avoid this case since it has class = c("model.frame",
"data.frame")
# see test case below where I figured out this issue in case it needs
further work.
class.x <- class(x)
caller <- sys.call(sys.parent())[[2]]
if (length(class.x)==1 && class.x=="data.frame" &&
(mode(caller) != "name" || (caller != "value"))) {
# If caller is a name and it is "value", then it is the
# lhs case that we just want the original fcn to handle:
result <- data.frame.original.fcn(x, ..., drop=F)
if (drop && length(ncol(result) > 0) && ncol(result)==1) {
save.names <- dimnames(result)[[1]]
#this approach works for factors too
result <- result[[1]]
names(result) <- save.names
# TODO: Unfortunately still broken for objects with new
# style classes, since it does not distinguish among
# methods that have or do not have a getnames method.
# library(missing) is an example: The multiple imputations
# on an object get lost if subscripted with this function.
} else {
if (!missing(drop) && drop && length(nrow(result)) > 0 &&
nrow(result)==1) {
#replicate documented behavior of [.data.frame: drop=T acts
#differently then missing drop arg fo
[Rd] cor doesn't accept na.rm? (PR#8193)
Full_Name: Paul Bailey Version: 2.1.1 OS: OS X 10.3 Submission from: (NULL) (68.252.250.144) ?cor [tells me that it has a na.rm variable] > cor(frame2[1,],frame2[2,],na.rm=T) Error in cor(frame2[1, ], frame2[2, ], na.rm = T) : unused argument(s) (na.rm ...) hmm. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cor doesn't accept na.rm? (PR#8193)
Where in ?cor do you see the na.rm argument? Mine says:
cor(x, y = NULL, use = "all.obs",
method = c("pearson", "kendall", "spearman"))
There's na.rm on that page, but that's for var(). Please read the R FAQ
more carefully about reporting bugs.
Andy
> From: [EMAIL PROTECTED]
>
> Full_Name: Paul Bailey
> Version: 2.1.1
> OS: OS X 10.3
> Submission from: (NULL) (68.252.250.144)
>
>
> ?cor
> [tells me that it has a na.rm variable]
>
> > cor(frame2[1,],frame2[2,],na.rm=T)
> Error in cor(frame2[1, ], frame2[2, ], na.rm = T) :
> unused argument(s) (na.rm ...)
>
> hmm.
>
> __
> 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] cor doesn't accept na.rm? (PR#8193)
On Mon, 10 Oct 2005 [EMAIL PROTECTED] wrote: > Full_Name: Paul Bailey > Version: 2.1.1 > OS: OS X 10.3 > Submission from: (NULL) (68.252.250.144) > > > ?cor > [tells me that it has a na.rm variable] >From which part of the man page do you infer that? (Hint: Which of the functions on that man page takes the na.rm argument?) > > cor(frame2[1,],frame2[2,],na.rm=T) > Error in cor(frame2[1, ], frame2[2, ], na.rm = T) : > unused argument(s) (na.rm ...) > > hmm. Look at the `use' argument of cor. Z P.S.: no bug, of course. > __ > 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] cor doesn't accept na.rm? (PR#8193)
On Mon, 2005-10-10 at 01:49 +0200, [EMAIL PROTECTED] wrote: > Full_Name: Paul Bailey > Version: 2.1.1 > OS: OS X 10.3 > Submission from: (NULL) (68.252.250.144) > > > ?cor > [tells me that it has a na.rm variable] > > > cor(frame2[1,],frame2[2,],na.rm=T) > Error in cor(frame2[1, ], frame2[2, ], na.rm = T) : > unused argument(s) (na.rm ...) > > hmm. Pray tell, where in ?cor do you see that cor() has a 'na.rm' argument? cor() has a 'use' argument, which determines how missing values are handled. Please read ?cor more carefully before filing a bug report, which now has to be manually handled by a member of R Core. Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Help page links to index.html are dead (PR#8196)
Full_Name: Kevin Wright Version: 2.2.0 OS: windows Submission from: (NULL) (66.185.0.208) On the help pages for R is a little circle with an up arrow that links to: file:///C:/R/R220/doc/html/index.htmlu This link is dead. I suspect the link should be: file:///C:/R/R220/doc/html/rwin.html P.S. It should be obvious, but just in case, I have R installed at c:/R/R220 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help page links to index.html are dead (PR#8196)
[EMAIL PROTECTED] wrote: > Full_Name: Kevin Wright > Version: 2.2.0 > OS: windows > Submission from: (NULL) (66.185.0.208) > > > > On the help pages for R is a little circle with an up arrow that links to: > > file:///C:/R/R220/doc/html/index.htmlu That's a typo in Kevin's message: the link is to .../doc/html/index.html. The link is correct, but the file was not installed. The Makefile creates it as a copy of rwin.html. Do you remember why we have both files? This bug has been around for a while... Duncan > > This link is dead. I suspect the link should be: > > file:///C:/R/R220/doc/html/rwin.html > > P.S. It should be obvious, but just in case, I have R installed at > c:/R/R220 > > __ > 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] Project suggestion: Interface between R and graphic devices
Simon Urbanek schrieb: >Knut, > >On Oct 9, 2005, at 1:19 PM, Knut Krueger wrote: > > > >>>If you prefer SciViews, JGR, R Commander, etc., then you should >>>expect >>>some delay before R releases and compatible GUI releases. Indeed, one >>>must say that R Commander has always been released on time with the >>>latest R version, as fart as I know, and JGR is very close to. >>> >>> >>> >>and this is the point that I thought maybe there could be some >>improvement with an universal API for GUIs >> >> > > >As Brian was pointing out there is such an API and as with all APIs >it is allowed to improve between releases. ... > Ok all your answers are clarifying the points of discussion about GUIs. I think I could say that I should not recommend a GUI which is not updated since the 1.4 Version. It seems to be that it was a "Mc Murphy" problem that I recommended SCIviews in the institute just a week before the compatibility was broken with the newest version. > From my point of view I can say that building and testing of >installers and binaries takes far more time than fixing the code for >API changes. If you are willing to build and test binaries during the >R beta phase, you're encouraged to do so - that would make the GUI >available right on time for the R release. > OK as I wrote, I am out of order with programming technique about 10 years now. A very long time for technical solutions. And I was working in a different language. I have small experience in C but lot in Assembler and Pascal (my biggest program of my own was about 65.000 lines). Pascal was required because it was very save for experimental and often changing programs. If you think I could start testing first and if this would be helpful I could start,. but I will have more time after January. But I am still a Newbie in R maybe there might be some problems and needless questions the first time. and maybe you are able to find tasks for the first steps in the community. Regards Knut [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help page links to index.html are dead (PR#8196)
On Mon, 10 Oct 2005, Duncan Murdoch wrote: > [EMAIL PROTECTED] wrote: >> Full_Name: Kevin Wright >> Version: 2.2.0 >> OS: windows >> Submission from: (NULL) (66.185.0.208) >> >> >> >> On the help pages for R is a little circle with an up arrow that links to: >> >> file:///C:/R/R220/doc/html/index.htmlu > > That's a typo in Kevin's message: the link is to .../doc/html/index.html. > The link is correct, but the file was not installed. The Makefile creates it > as a copy of rwin.html. Do you remember why we have both files? This bug > has been around for a while... Yes, rwin.html contains an additional link to rw-FAQ.html. Now the Windows index.html should be the same: indeed, it is installed as such by fixed/Makefile. So it's a bug in building the installer. If you are asking why rwin.html is needed: until recently the sources contained doc/html/index.html so it was likely to be restored. It seems to me there is another error in the message: the help pages contain no such link (which threw me for a while). It does appear on the summary page for a package, and on packages.html. >> This link is dead. I suspect the link should be: >> >> file:///C:/R/R220/doc/html/rwin.html >> >> P.S. It should be obvious, but just in case, I have R installed at >> c:/R/R220 >> >> __ >> 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
