[Rd] read.fwf; bug reports 8226 & 8236 (PR#8284)
It seems to me that the bug dealt with in bug reports 8226 and 8236
is still not fixed.
I obtained the revised version of read.fwf from the latest
R-patched and tried
try.it <- read.fwf("junk",w,header=TRUE,as.is=TRUE)
This gave the error
Error in read.table(file = FILE, header = header, sep = sep, as.is = as.is, :
more columns than column names
Inspection of file ``FILE'' revealed that (of course) the
first line of ``FILE'' was not tab separated and was hence
being treated as a single field.
I then tried the last of Emmanuel Paradis' proposed fixes; this
didn't quite work --- an extra ``sep'' (tab) gets tacked on at the
end of the line being catted and makes read.table think that there is
one more field than there actually are.
So I modified the fix to:
if (header) {
headerline <- readLines(file, n = 1)
head.last <- cumsum(widths)
head.first <- head.last - widths + 1
headerline <- substring(headerline,head.first,head.last)[!drop]
headerline <- paste(headerline,collapse=sep)
cat(file = FILE, headerline, "\n")
}
This works for me.
Brian Ripley says that this will crash with multiline records. Well,
at least it works with single line records, as the current version
seems not to.
cheers,
Rolf Turner
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to make install DESTDIR=
Hello, I tried to do make install DESTDIR=$PKGDIR. But this does not work. What is the alternative? I need to do this to create Slackware package. Thanks for your help, Anand __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to make install DESTDIR=
On 5 November 2005 at 22:52, R S Ananda Murthy wrote: | I tried to do make install DESTDIR=$PKGDIR. But this does not work. What | is the alternative? I need to do this to create Slackware package. I think you want make prefix=$PKGDIR install as the documentation in R-admin states rather clearly in several places. Hth, Dirk -- Statistics: The (futile) attempt to offer certainty about uncertainty. -- Roger Koenker, 'Dictionary of Received Ideas of Statistics' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] clarification of library/require semantics
On 4 Nov 2005, [EMAIL PROTECTED] wrote: > I set my standard libraries in R_LIBS, so when I use lib.loc it is > for experimental things. So I would neither want the .libPaths > changed nor be affected if they were. With the current semantics, if one is testing a _collection_ of experimental packages that depend on each other, the only way to test the collection is to modify .libPaths. Setting lib.loc only allows one to test a single experimental package against dependencies picked up from R_LIBS. Robert's proposal, as I understand it, would change the meaning of lib.loc so that dependencies would be resolved there --- allowing a collection of experimental packages to be tested against each other. The current behavior could be replicated in this case by putting a given experimental package in a library by itself. Clearly, each choice has a tradeoff. I understand that if one most often tests a single independent experimental package, then the current behavior is most convenient. My preference is for lib.loc grabbing dependencies because I more often deal with packages that have dependencies that I want to test together. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Brainstorm: Alpha and Beta testing of R versions
Hi Martin, On Fri, Nov 04, 2005 at 09:58:47AM +0100, Martin Maechler wrote: > [Mainly for R-foundation members; but kept in public for general > brainstorming...] I'll take up the invitation to brainstorm. As a user of R for a number of years, I'd really like to perform some useful service. I use a relatively obscure platform (FreeBSD) and I can compile code. I'd like to think that I'm in the target market for beta testing :). But, I'm timid. I do not feel, in general, that R core welcomes bug reports. I think that there are several things that could be tried to encourage more, and more useful, bug reports. 1) Put the following text on the *front page* of the tracking system, so that it is seen before the reader clicks on "New Bug Report": "Before submitting a bug report, please read Chapter `R Bugs' of `The R FAQ'. It describes what a bug is and how to report a bug. If you are not sure whether you have observed a bug or not, it is a good idea to ask on the mailing list R-Help by sending an e-mail to r-help@stat.math.ethz.ch rather than submitting a bug report." (BTW is this true also for alpha/beta testing?) 2) Try to use the structure of the reporting page to prompt good reporting. On the report page, summarize the key points of identifying and reporting a bug in a checklist format. Maybe even insist that the boxes be checked before allowing submission. Include seperate text boxes for description and sample code, to suggest that sample code is valued. 3) On either or both pages (and in FAQ), explain that thoughtful bug reports are valued and appreciated. Further, explain that bug reports that do not follow the protocol are less valuable, and take more time. 4) Add checkboxes to the report page for alpha/beta. (I suggest this for the purposes of marketing, not organization.) 5) On the report page, include hyperlinks to archived bug reports that were good. Do likewise with some artificial bug reports that are bad. 6) Add an intermediate, draft step for bug submission, to allow checking. If possible, include as part of this step an automated pattern matching call that identifies similarly texted bug reports, provides links to the reports, and invites a last-minute cross-check. 7) Keep a list of people who report useful bugs in alpha/beta phase on the website. Many academics could point to it as evidence of community service. > In order to discourage an increased number of non-bug reports we > may have to also open a "hall of shame" though... 8) I'm sure that you're being ironic! But I will take the point seriously, for what it's worth. I think that humiliating submitters who haven't followed the protocol is deleterious. It seems like almost every month we see someone get slapped on the wrist for not doing something the right way. Of course, it's frustrating that people aren't following the posting guide. But, why is that? Where is the breakdown? It might be interesting to try some follow-up (an exit interview!). If someone has failed to follow the protocol, perhaps we should try to find out why it was confusing, or if they just ignored it. The R-core is surrounded by, and serves, a community that comprises people who are not sufficiently good at what R-core does to be invited in to R-core. But, we're clearly interested in what R-core produces. Please don't assume that bug submissions that do not follow the R protocol are the consequence of deliberate malfeasance. To paraphrase Ian Fleming: Once is happenstance. Twice is incompetence. The third time, Mr. Bond, is enemy action. So, ... 9) Publicly thank bug reporters whether their reports are useful or not. I just googled 'R-devel thank' and you figure prominently, Martin :). Cheers Andrew -- Andrew Robinson Senior Lecturer in Statistics Tel: +61-3-8344-9763 Department of Mathematics and StatisticsFax: +61-3-8344-4599 University of Melbourne, VIC 3010 Australia Email: [EMAIL PROTECTED]Website: http://www.ms.unimelb.edu.au __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Brainstorm: Alpha and Beta testing of R versions
Andrew Robinson wrote: >Hi Martin, > >On Fri, Nov 04, 2005 at 09:58:47AM +0100, Martin Maechler wrote: > > >>[Mainly for R-foundation members; but kept in public for general >> brainstorming...] >> >> > >I'll take up the invitation to brainstorm. > >As a user of R for a number of years, I'd really like to perform some >useful service. I use a relatively obscure platform (FreeBSD) and I >can compile code. I'd like to think that I'm in the target market for >beta testing :). But, I'm timid. I do not feel, in general, that R >core welcomes bug reports. > >I think that there are several things that could be tried to encourage >more, and more useful, bug reports. > >1) Put the following text on the *front page* of the tracking system, so > that it is seen before the reader clicks on "New Bug Report": > >"Before submitting a bug report, please read Chapter `R Bugs' of `The >R FAQ'. It describes what a bug is and how to report a bug. > >If you are not sure whether you have observed a bug or not, it is a >good idea to ask on the mailing list R-Help by sending an e-mail to >r-help@stat.math.ethz.ch rather than submitting a bug report." > >(BTW is this true also for alpha/beta testing?) > >2) Try to use the structure of the reporting page to prompt good > reporting. On the report page, summarize the key points of > identifying and reporting a bug in a checklist format. Maybe even > insist that the boxes be checked before allowing submission. > Include seperate text boxes for description and sample code, to > suggest that sample code is valued. > > ...and a optional field to select one or several packages related to the bug. This is a good place to clarify that problems related to third-party packages should not be reporter "here". Example HTML code: Package(s) related to the bug, if applicable: (Bugs related to packages not listed below should not be reported here. Instead, contact the package manager.) - - Select one or more packages related to the bug - - base (Base R functions) datasets (Base R datasets) grDevices (Graphics devices for base and grid graphics) graphics (R functions for base graphics) grid (A rewrite of the graphics layout capabilities, plus some support for interaction) methods (Formally defined methods and classes for R objects, plus other programming tools, as described in the Green Book) splines (Regression spline functions and classes) stats (R statistical functions) stats4 (Statistical functions using S4 classes) tcltk (Interface and language bindings to Tcl/Tk GUI elements) tools (Tools for package development and administration) utils (R utility functions) /Henrik >3) On either or both pages (and in FAQ), explain that thoughtful bug > reports are valued and appreciated. Further, explain that bug > reports that do not follow the protocol are less valuable, and take > more time. > >4) Add checkboxes to the report page for alpha/beta. (I suggest this > for the purposes of marketing, not organization.) > >5) On the report page, include hyperlinks to archived bug reports that > were good. Do likewise with some artificial bug reports that are > bad. > >6) Add an intermediate, draft step for bug submission, to allow > checking. If possible, include as part of this step an automated > pattern matching call that identifies similarly texted bug reports, > provides links to the reports, and invites a last-minute cross-check. > >7) Keep a list of people who report useful bugs in alpha/beta phase on > the website. Many academics could point to it as evidence of > community service. > > > >>In order to discourage an increased number of non-bug reports we >>may have to also open a "hall of shame" though... >> >> > >8) I'm sure that you're being ironic! But I will take the point > seriously, for what it's worth. I think that humiliating > submitters who haven't followed the protocol is deleterious. It > seems like almost every month we see someone get slapped on the > wrist for not doing something the right way. Of course, it's > frustrating that people aren't following the posting guide. But, > why is that? Where is the breakdown? It might be interesting to > try some follow-up (an exit interview!). If someone has failed to > follow the protocol, perhaps we should try to find out why it was > confusing, or if they just ignored it. > > The R-core is surrounded by, and serves, a community that comprises > people who are not sufficiently good at what R-core does to be > invited in to R-core. But, we're clearly interested in what R-core > produces. Please don't assume that bug submissions that do not > follow the R protocol are the consequence of deliberate > malfeasance. > > To paraphrase Ian Fleming: Once is happenstance. Twice is > incompetence. The third time, Mr. Bond, is enemy action. So, ... > >9) Publicly thank bug reporters whether their reports are useful or > n
