Re: [Rd] read.fwf doesn't work with header = TRUE (PR#8226)
On Thu, 20 Oct 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Emmanuel Paradis
> Version: 2.1.1
> OS: Linux
> Submission from: (NULL) (193.49.41.105)
>
>
> read.fwf(..., header = TRUE) does not work properly since:
>
> 1/ the original header is printed on the console and not in FILE;
> 2/ the different 'parts' of the header should be separated with tabs
> to work with the call to read.table.
>
> Here is a suggested fix for src/library/utils/R/read.fwf.R:
>
> 38c38,40
> < cat(FILE, headerline, "\n")
> ---
>> headerline <- unlist(strsplit(headerline, " {1,}"))
>> headerline <- paste(headerline, collapse = "\t")
>> cat(file = FILE, headerline, "\n")
Thanks, but I don't think that is right. It assumes the header line is
space-delimited (or at least that spaces get converted to tabs). We have
not specified the format of the header line, and it cannot usefully be
fixed format. So I think we need to specify it is delimited by 'sep'
(not tab).
--
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] read.fwf(...,header=TRUE,...) (PR#8236)
Full_Name: Giovanni Bonafe' Version: 2.2.0 OS: Linux Submission from: (NULL) (195.62.164.225) If the file "example.dat" is like this: aaa bbb ccc 3.4 1.2 5.6 4.6 10 32 667 343 1.7 With the older 1.9.1, as expected: > data<-read.fwf(file = "example.dat",widths=c(3,4,4),header=TRUE) > data aaa bbb ccc 1 3.4 1.2 5.6 2 4.6 10.0 32.0 3 667.0 343.0 1.7 While with the newer 2.2.0: > data<-read.fwf(file = "example.dat",widths=c(3,4,4),header=TRUE) > data X3.4 X1.2 X5.6 1 4.6 10 32.0 2 667.0 343 1.7 On the other side, if I use the option header=FALSE, no difference occurs between the two versions: > data<-read.fwf(file = "example.dat",widths=c(3,4,4)) > data V1 V2 V3 1 aaa bbb ccc 2 3.4 1.2 5.6 3 4.6 1032 4 667 343 1.7 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.table error upon package installation (PR#8230)
Thanks for this. I tried switching the file extension from txt to tab, but it seems to still split on whitespace rather than tabs. My goal is to create a file that is both readable by R and by a spreadsheet program, and that may contain white spaces. If tab-delimited separation is not currently supported on load time, a CSV file would also be a natural candidate. Unfortunately for me, it seems that R expects the CSV file in the 'data' subdirectory to be delimited by semi-colons rather than commas (which seems odd and might be worthy of mention in the Writing R Extensions Manual), and the particular spread-sheet program I use uses commas to delimit CSV files. So, then, I think that I will be unable to use 'data' subdirectory to load this data using data(), but any feedback on this is welcomed. Thanks, Robert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, October 21, 2005 1:58 AM To: r-devel@stat.math.ethz.ch Cc: [EMAIL PROTECTED] Subject: Re: [Rd] read.table error upon package installation (PR#8230) What is the R error here? The default delimiter in read.table is not \t but whitespace, so the first example has 2 and 3 rows (fine for header=T) and the second has 2 and 4 rows. On Fri, 21 Oct 2005 [EMAIL PROTECTED] wrote: > Upon upgrading to R 2.2.0 on my Windows box, I found that one of my > packages no longer compiled, giving this error: > > Error in read.table(zfile, header =3D TRUE) : > more columns than column names > Execution halted > > After removing every line of code from my package and still not being > able to compile it, I found the error to be related to a .txt file in my > data directory. I reduced my data file to a very simple example which > causes the error, and a nearly identical file which does not cause the > problem. > > A file with these contents causes the error (I am using \t to indicate > the usual tab delimiter). > x \t y > A B C \t DEF > > However, if I remove one of the spaces between A and B or B and C, the > package compiles fine: > x \t y > A BC \t DEF > > I can only guess that there is some kind of parsing problem when there > is more than one space between tab delimiters. Looks more like a user misunderstanding of ?data. -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.table error upon package installation (PR#8230)
On Fri, 21 Oct 2005, McGehee, Robert wrote: > Thanks for this. > > I tried switching the file extension from txt to tab, but it seems to > still split on whitespace rather than tabs. > > My goal is to create a file that is both readable by R and by a > spreadsheet program, and that may contain white spaces. If tab-delimited > separation is not currently supported on load time, a CSV file would > also be a natural candidate. Unfortunately for me, it seems that R > expects the CSV file in the 'data' subdirectory to be delimited by > semi-colons rather than commas (which seems odd and might be worthy of > mention in the Writing R Extensions Manual), and the particular > spread-sheet program I use uses commas to delimit CSV files. So, then, I > think that I will be unable to use 'data' subdirectory to load this data > using data(), but any feedback on this is welcomed. Using quotes, e.g. "A B C" may work? > > Thanks, > Robert > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, October 21, 2005 1:58 AM > To: r-devel@stat.math.ethz.ch > Cc: [EMAIL PROTECTED] > Subject: Re: [Rd] read.table error upon package installation (PR#8230) > > > What is the R error here? > > The default delimiter in read.table is not \t but whitespace, so the > first > example has 2 and 3 rows (fine for header=T) and the second has 2 and 4 > rows. > > On Fri, 21 Oct 2005 [EMAIL PROTECTED] wrote: > >> Upon upgrading to R 2.2.0 on my Windows box, I found that one of my >> packages no longer compiled, giving this error: >> >> Error in read.table(zfile, header =3D TRUE) : >> more columns than column names >> Execution halted >> >> After removing every line of code from my package and still not being >> able to compile it, I found the error to be related to a .txt file in > my >> data directory. I reduced my data file to a very simple example which >> causes the error, and a nearly identical file which does not cause the >> problem. >> >> A file with these contents causes the error (I am using \t to indicate >> the usual tab delimiter). >> x\t y >> A B C\t DEF >> >> However, if I remove one of the spaces between A and B or B and C, the >> package compiles fine: >> x\t y >> A BC \t DEF >> >> I can only guess that there is some kind of parsing problem when there >> is more than one space between tab delimiters. > > Looks more like a user misunderstanding of ?data. > > -- > 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 > > -- 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] read.fwf(...,header=TRUE,...) (PR#8236)
This is the same as PR#8226, and is already fixed in R-patched. Please note the searches you were asked to do before submitting a report. On Fri, 21 Oct 2005 [EMAIL PROTECTED] wrote: > Full_Name: Giovanni Bonafe' > Version: 2.2.0 > OS: Linux > Submission from: (NULL) (195.62.164.225) > > > If the file "example.dat" is like this: > > aaa bbb ccc > 3.4 1.2 5.6 > 4.6 10 32 > 667 343 1.7 > > With the older 1.9.1, as expected: > >> data<-read.fwf(file = "example.dat",widths=c(3,4,4),header=TRUE) >> data >aaa bbb ccc > 1 3.4 1.2 5.6 > 2 4.6 10.0 32.0 > 3 667.0 343.0 1.7 > > While with the newer 2.2.0: > >> data<-read.fwf(file = "example.dat",widths=c(3,4,4),header=TRUE) >> data > X3.4 X1.2 X5.6 > 1 4.6 10 32.0 > 2 667.0 343 1.7 > > On the other side, if I use the option header=FALSE, no difference occurs > between the two versions: > >> data<-read.fwf(file = "example.dat",widths=c(3,4,4)) >> data > V1 V2 V3 > 1 aaa bbb ccc > 2 3.4 1.2 5.6 > 3 4.6 1032 > 4 667 343 1.7 > > __ > 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] read.table error upon package installation (PR#8230)
Yes, but only, it seems, if you put quotes around all the fields (not just the "A B C"). Also a note to Excel users, when adding quotes as suggested "A B C" is saved as """A B C""" which R reads in differently than Excel. For my purposes though, everyone who needs to edit this file can just do so in emacs, and putting quotes around the fields is an easy fix. Thanks Robert -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Friday, October 21, 2005 9:59 AM To: McGehee, Robert Cc: r-devel@stat.math.ethz.ch Subject: RE: [Rd] read.table error upon package installation (PR#8230) On Fri, 21 Oct 2005, McGehee, Robert wrote: > Thanks for this. > > I tried switching the file extension from txt to tab, but it seems to > still split on whitespace rather than tabs. > > My goal is to create a file that is both readable by R and by a > spreadsheet program, and that may contain white spaces. If tab-delimited > separation is not currently supported on load time, a CSV file would > also be a natural candidate. Unfortunately for me, it seems that R > expects the CSV file in the 'data' subdirectory to be delimited by > semi-colons rather than commas (which seems odd and might be worthy of > mention in the Writing R Extensions Manual), and the particular > spread-sheet program I use uses commas to delimit CSV files. So, then, I > think that I will be unable to use 'data' subdirectory to load this data > using data(), but any feedback on this is welcomed. Using quotes, e.g. "A B C" may work? > > Thanks, > Robert > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, October 21, 2005 1:58 AM > To: r-devel@stat.math.ethz.ch > Cc: [EMAIL PROTECTED] > Subject: Re: [Rd] read.table error upon package installation (PR#8230) > > > What is the R error here? > > The default delimiter in read.table is not \t but whitespace, so the > first > example has 2 and 3 rows (fine for header=T) and the second has 2 and 4 > rows. > > On Fri, 21 Oct 2005 [EMAIL PROTECTED] wrote: > >> Upon upgrading to R 2.2.0 on my Windows box, I found that one of my >> packages no longer compiled, giving this error: >> >> Error in read.table(zfile, header =3D TRUE) : >> more columns than column names >> Execution halted >> >> After removing every line of code from my package and still not being >> able to compile it, I found the error to be related to a .txt file in > my >> data directory. I reduced my data file to a very simple example which >> causes the error, and a nearly identical file which does not cause the >> problem. >> >> A file with these contents causes the error (I am using \t to indicate >> the usual tab delimiter). >> x\t y >> A B C\t DEF >> >> However, if I remove one of the spaces between A and B or B and C, the >> package compiles fine: >> x\t y >> A BC \t DEF >> >> I can only guess that there is some kind of parsing problem when there >> is more than one space between tab delimiters. > > Looks more like a user misunderstanding of ?data. > > -- > 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 > > -- 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] Problems with example(Grid) in grid package
The following: library(grid) grid.newpage() example(Grid) has the yaxis label partly cut off and the x axis label does not appear at all. Also ?grid.multipanel in that example brings up documentation for grid-internal but this would not seem to be internal if its part of an example. I am using: > R.version.string # Windows XP [1] "R version 2.2.0, 2005-09-20" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] new.packages() reports on packages installed with the install.packages option installWithVers=TRUE (PR#8237)
Full_Name: AJ Rossini Version: 2.2.0-patched OS: RH9 Submission from: (NULL) (160.62.4.10) (perhaps the search mechanism of the bugtracker is broken, I can't find my old bug report -- but it's still broken) new.packages() is only supposed to report on packages which are not installed. When the packages are installed with installWithVers=TRUE, new.packages() reports on installed packages. This is a bug. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.fwf doesn't work with header = TRUE (PR#8226)
Prof Brian Ripley wrote:
> On Thu, 20 Oct 2005 [EMAIL PROTECTED] wrote:
>
>> Full_Name: Emmanuel Paradis
>> Version: 2.1.1
>> OS: Linux
>> Submission from: (NULL) (193.49.41.105)
>>
>>
>> read.fwf(..., header = TRUE) does not work properly since:
>>
>> 1/ the original header is printed on the console and not in FILE;
>> 2/ the different 'parts' of the header should be separated with tabs
>> to work with the call to read.table.
>>
>> Here is a suggested fix for src/library/utils/R/read.fwf.R:
>>
>> 38c38,40
>> < cat(FILE, headerline, "\n")
>> ---
>>
>>> headerline <- unlist(strsplit(headerline, " {1,}"))
>>> headerline <- paste(headerline, collapse = "\t")
>>> cat(file = FILE, headerline, "\n")
>
>
> Thanks, but I don't think that is right. It assumes the header line is
> space-delimited (or at least that spaces get converted to tabs). We
> have not specified the format of the header line, and it cannot usefully
> be fixed format. So I think we need to specify it is delimited by 'sep'
> (not tab).
I see, but suppose we read selectively some columns in a file, eg with
widths=c(1, -4, 2), how can we know how many variables have been skipped
and then select the appropriate names in the header line?
Here is another proposed fix, but this assumes the header line is in
fixed-width format (as specified by 'widths'):
38c38,41
< cat(FILE, headerline, "\n")
---
> head.last <- cumsum(widths)
> head.first <- head.last - widths + 1
> headerline <- substring(headerline, head.first, head.last)[drop]
> cat(file = FILE, headerline, "\n", sep = sep)
?read.fwf says clearly that sep is used internally.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
James Wettenhall schreef op de 21e dag van de wijnmaand van het jaar 2005: > We may have to agree to disagree about some things, but I hope > this has made my point of view a little clearer. Actually, your elaborate response makes much sense to me. I understand now that it is not just about replacing the command line with a GUI. It is not like LaTeX versus Word (i.e. good versus bad), but about organising and streamlining tasks, doing "higher level" things. At least, that is what I think it is. This is a topic I have been struggling with for quite some time. For years, I have been working on software for dialectometrics and cartography. At the beginning, just for doing research at our institute. But soon, it developed into something people from other institutes can use. A large set of command line programs, manual pages, an R interface, and quite an extensive tutorial with example material. My employer urged me to add some sort of GUI. It would make more people willing to try using the software. I resisted the idea of a GUI. For one thing, I work on Linux but the GUI should be used on Windows. (Java is too bothersome. Smalltalk too clumsy. And I didn't know about Python yet.) But the main problem was: I had no idea what a GUI should look like, what it was supposed to do. It took me quite some time, working with my own software, before I was able to look at it from a distance. The software is just a toolkit. I didn't want a Graphical Toolkit. What I wanted was something like a Graphical Project Manager, something task oriented, with and interactive help system that guides the user through the work. It is still fresh. I haven't had any responses on people using the GUI, so I don't know yet if this is what people helps. What I still think as one of the biggest obstacles for using my software is not cured by the GUI. You still need to select and prepare the data. If you want maps, you have to provide map data, in a format the software understands. This GUI I built is quite specific. It assumes a quite narrow purpose (though parts of the software can be used independently for quite other purposes): you start with a set of dialect data, you do some calculations on that data to make estimates of differences between dialects, and you visualise these dialect differences on a geographic map. I still don't see anything like that for R. A general GUI for R? What are the "higher level task" you use R for? It only makes sense to me if you want to use R in a specific field, such as in Bioconductor. You build a GUI to that specific higher level application of R. Or does anyone want to transform R into something like a spreadsheet program? There are people making a GUI for LaTeX to make it look like Word, a WYSIWYG, but to me that seems like a very silly thing to do. For those interested, here is my software: http://www.let.rug.nl/~kleiweg/L04/ And the GUI is here: http://www.let.rug.nl/~kleiweg/L04/pyL04/ -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with example(Grid) in grid package
I've also noticed the behaviour of grid.rect() has changed in 2.2.0. Before the fill defaulted to transparent, but now it defaults to white. Hadley On 10/21/05, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > The following: > > library(grid) > grid.newpage() > example(Grid) > > has the yaxis label partly cut off and the x axis label does not appear at > all. > Also ?grid.multipanel in that example brings up documentation for > grid-internal but this would not seem to be internal if its part of an > example. > > I am using: > > > R.version.string # Windows XP > [1] "R version 2.2.0, 2005-09-20" > > __ > 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] Single vs. dual CPUs
I've posted this earlier and have not heard much so far. I'd really appreciate any guidance on this as we are about to order new hardware. We are buying Dell workstations with Red Hat Linux and 64-bit Xeon CPUs to run R. We could add a second processor to each system, or buy slightly faster single CPU systems. Is it possible to make a generalized statement as to what kind of performance improvement we would see with a single vs. dual processors when running R on these systems? Thanks again. Milton F. López IT Guy Inter-American Tuna Commission (IATTC) 8604 La Jolla Shores Drive La Jolla, CA 92037 Tel: (858) 546-7041, Fax: (858) 546-7133 [EMAIL PROTECTED] http://www.iattc.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in building package indices
Dear Prof. Ripley,
Thanks for your suggestion.
Yes, R CMD INSTALL also failed and the problem was indeed in the data
directory.
There were some files (.R) in the data directory, which were creating the
error.
After removing them, R CMD check works fine.
Best,
Nitin
-Original Message-
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 20, 2005 5:39 PM
To: Jain, Nitin
Cc: '[EMAIL PROTECTED]'
Subject: Re: [Rd] Error in building package indices
There is not much context here, but it seems this is whilst trying to do
an install. I would expect R CMD INSTALL to fail in the same place.
It appears to indicate a bug in one of your datasets.
On Thu, 20 Oct 2005, Jain, Nitin wrote:
> Dear R-devel members,
>
> We are building a new package (GeneticsBase) for analysis of genetic data
.
> While doing "R CMD check with R-2.1.1, I am getting the following error:
>
> ** building package indices ...
> Error in "colnames<-"(`*tmp*`, value = c("family", "pid", "father",
> "mother", :
>length of 'dimnames' [2] not equal to array extent
> Execution halted
> ERROR: installing package indices failed
> ERROR
> Installation failed.
>
> We believe that this could be due to package versioning, but are not sure.
Not sure what you mean here. No versioning is being used by R CMD check.
--
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
--
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Single vs. dual CPUs
"Milton Lopez" <[EMAIL PROTECTED]> writes: > I've posted this earlier and have not heard much so far. I'd really > appreciate any guidance on this as we are about to order new hardware. > > We are buying Dell workstations with Red Hat Linux and 64-bit Xeon > CPUs to run R. We could add a second processor to each system, or > buy slightly faster single CPU systems. Is it possible to make a > generalized statement as to what kind of performance improvement we > would see with a single vs. dual processors when running R on these > systems? Well, if you ask that way, the answer is probably no... It depends on the usage pattern. If you run multiple CPU-bound processes in parallel without too much coordination (parallel make is a good example, simulations another), then you get close to double up from a dual. For a single R process, you can get something like 40% improvement in large linear algebra problems, using a threaded ATLAS. For other problems the speedup is basically nil. There is some potential in threading R or (much easier) some of its vector operations, but that is not even on the drawing board at this stage. Also, these days you might want to consider another factor: noise. Duals tend to be server machines with little emphasis on quietness, where the single-CPU machines have heatpipes and whatnot. -- 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] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
On Oct 21, 2005, at 8:53 AM, Peter Kleiweg wrote: > James Wettenhall schreef op de 21e dag van de wijnmaand van het > jaar 2005: > > >> We may have to agree to disagree about some things, but I hope >> this has made my point of view a little clearer. >> > > Actually, your elaborate response makes much sense to me. I > understand now that it is not just about replacing the command > line with a GUI. It is not like LaTeX versus Word (i.e. good > versus bad), but about organising and streamlining tasks, doing > "higher level" things. At least, that is what I think it is. > > This is a topic I have been struggling with for quite some time. > For years, I have been working on software for dialectometrics > and cartography. At the beginning, just for doing research at > our institute. But soon, it developed into something people from > other institutes can use. A large set of command line programs, > manual pages, an R interface, and quite an extensive tutorial > with example material. > > My employer urged me to add some sort of GUI. It would make more > people willing to try using the software. I resisted the idea of > a GUI. For one thing, I work on Linux but the GUI should be used > on Windows. (Java is too bothersome. Smalltalk too clumsy. And I > didn't know about Python yet.) But the main problem was: I had > no idea what a GUI should look like, what it was supposed to do. > It took me quite some time, working with my own software, before > I was able to look at it from a distance. The software is just a > toolkit. I didn't want a Graphical Toolkit. What I wanted was > something like a Graphical Project Manager, something task > oriented, with and interactive help system that guides the user > through the work. > > It is still fresh. I haven't had any responses on people using > the GUI, so I don't know yet if this is what people helps. What > I still think as one of the biggest obstacles for using my > software is not cured by the GUI. You still need to select and > prepare the data. If you want maps, you have to provide map > data, in a format the software understands. For the applications James have in mind, the data format is basically standardized. From a certain level you might think of every observation residing in a separate file (in one out of a couple of different file formats), so all the user has to do is choose "file format" and basically label every file with eg. "control"/"treatment". This is somewhat simplifying of course, but basically the data input step is much more simple than in "general" cases. > This GUI I built is quite specific. It assumes a quite narrow > purpose (though parts of the software can be used independently > for quite other purposes): you start with a set of dialect data, > you do some calculations on that data to make estimates of > differences between dialects, and you visualise these dialect > differences on a geographic map. > > I still don't see anything like that for R. A general GUI for R? > What are the "higher level task" you use R for? It only makes > sense to me if you want to use R in a specific field, such as in > Bioconductor. You build a GUI to that specific higher level > application of R. Yes, and this is exactly what James have been doing. > Or does anyone want to transform R into something like a > spreadsheet program? There are people making a GUI for LaTeX to > make it look like Word, a WYSIWYG, but to me that seems like a > very silly thing to do. Agreed, although I am humble enough to know that there might be sense in doing so from a certain perspective which I am not aware of. Kasper > For those interested, here is my software: > > http://www.let.rug.nl/~kleiweg/L04/ > > And the GUI is here: > > http://www.let.rug.nl/~kleiweg/L04/pyL04/ > > -- > Peter Kleiweg > http://www.let.rug.nl/~kleiweg/ > > __ > 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] new.packages --- wishlist (PR#8239)
new.packages() misses a destdir argument as in update.packages() and install.packages(). Adding this new argument is very little work, so please do it! Kjetil -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
