Re: [Rd] Citation for R
>>>>> On Tue, 14 Jun 2005 10:38:38 +1000,
>>>>> Gordon Smyth (GS) wrote:
>> Note also that R does have a User Guide, i.e., while there is plenty of
>> excellent documentation,
>> there is no single document which is a guide to the whole project.
> Oops, I meant to write "R does not have a User Guide".
> Just to explain this further, the citation() function asks me to cite a
> "Manual" with the title "R: A language and environment for statistical
> computing". Although R comes with excellent documentation, including at
> least 6 manuals on different aspects of the software, no manual or document
> with that title actually exists, as far as I know.
The Reference Index (all help Pages in one PDF document) has that name
("Reference Index" is actually the subtitle), and you can download it
from
http://cran.r-project.org/manuals.html
(it's the 12MB guy at the end of the list of manuals). The ISBN rules
make it possible to cover both a software package and it's
corresponding reference manual by one single ISBN number if they are
bundled tightly and that's what we did for R. So as far as citations
go this should be as good a reference as any printed book. ISBN does not
require the item to be available for sale in printed form, electronic
publication is sufficient, see
http://www.isbn-international.org/en/userman/chapter6.html
The only open question is how many ISBN number we need exactly for R
(every patch release, every minor release etc.). I had a short
discussion with the Austrian ISBN representative and he recommended
for a fast-changing work like R to consider it like a database or
encyclopedia (which is true for the help pages anyway), and be rather
pragmatic. Hence we assigned a new ISBN to version 2.0.0 and will do so
again for 3.0.0.
Best,
--
---
Friedrich Leisch
Institut für Statistik Tel: (+43 1) 58801 10715
Technische Universität WienFax: (+43 1) 58801 10798
Wiedner Hauptstraße 8-10/1071
A-1040 Wien, Austria http://www.ci.tuwien.ac.at/~leisch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Citation for R
> On Tue, 14 Jun 2005 08:42:59 +1000 (EST), > Gordon K Smyth (GKS) wrote: > On Tue, June 14, 2005 12:49 am, Thomas Lumley said: >> On Mon, 13 Jun 2005, Gordon K Smyth wrote: >> >>> This is just a note that R would get a lot more citations if the >>> recommended citation was an article in a recognised journal or from a >>> recognised publisher. >>> >> >> This is unfortunately true, but R is *not* an article or a book, it is a >> piece of software. I don't think I'm the only person who thinks it is >> counterproductive in the long run to encourage users to cite an article >> that they probably haven't read instead of citing the software they >> actually used. >> >> Jan's suggestion of the Journal of Statistical Software might provide a >> solution, since JSS *does* publish software. >> >> -thomas > In the biology world, it is common to publish an article > announcing a software project, and to cite that. The referees of > the article are expected to try out and comment on the software. > This gives the authors credit, and ensures that both the article > and the software have been peer refereed, at least to a limited > extent. How do you cite books in this world, or to but the question in another way: How do you make sure a book is peer-reviewd? After all it is quite easy to become a "publisher" and publish ones own books. Many university departments I know are registered ISBN publishers (including our department). Must be hard to distinguish "real" books from others, I guess. Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Additional Books on R for Web Site Listing
>>>>> On Sun, 28 Aug 2005 17:30:24 -0500, >>>>> Marc Schwartz (MS) wrote: > Hi all, > I noted that the books below are not included on the R web site > Documentation section under "Books". I thought that I would provide > these and have created some bib entries consistent with the style used > on the site. The abstract sections were copied from the publisher > sites. Thanks a lot, I have added them to the list (will go live later today). Best, Fritz -- ------- Friedrich Leisch Institut für Statistik Tel: (+43 1) 58801 10715 Technische Universität WienFax: (+43 1) 58801 10798 Wiedner Hauptstraße 8-10/1071 A-1040 Wien, Austria http://www.ci.tuwien.ac.at/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
> On Fri, 9 Sep 2005 10:33:03 -0700 (PDT), > Thomas Lumley (TL) wrote: > On Fri, 9 Sep 2005, Gabor Grothendieck wrote: >> >> I personally put NEWS, WISHLIST and THANKS files in the 'inst' >> directory of all my source packages. This has the effect of copying them to the >> top level of the built version so that they are accessible from R via: >> > I'm not sure that WISHLIST and THANKS need to be available to people who > haven't installed the package. NEWS, on the other hand, really does. > One option (if it doesn't turn out to be too much work for the CRAN > maintainers) would be to have an optional Changelog field in the > DESCRIPTION file giving the relative path to the file. This would mean > that maintainers would not all have to switch to the same format. > eg for foreign >Changelog: ChangeLog > and for survey >Changelog: inst/NEWS > This might be enough to make it easy for CRAN to display these when the > maintainer provides them. Standard location or a mechachanism like the one you describe are both similar amount of work (and not much at all), the HTML pages are generated by perl and I have the parsed DESCRIPTION file there, i.e., using a fixed name or the value of the Changelog field is basically the same. .f __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue tracking in packages [was: Re: [R] change in read.spss, package foreign?]
> On Sat, 10 Sep 2005 19:06:51 +0200,
> Martin Maechler (MM) wrote:
> "TL" == Thomas Lumley <[EMAIL PROTECTED]>
> on Sat, 10 Sep 2005 09:32:29 -0700 (PDT) writes:
>>> Standard location or a mechachanism like the one you
>>> describe are both similar amount of work (and not much at
>>> all), the HTML pages are generated by perl and I have the
>>> parsed DESCRIPTION file there, i.e., using a fixed name
>>> or the value of the Changelog field is basically the
>>> same.
>>>
TL> In which case a Changlog entry in DESCRIPTION would be a
TL> very nice addition, and would have the advantage of not
TL> requiring changes to packages.
> yes *and* does allow slightly more flexibility with almost
> no cost, as Fritz confirmed.
Well, as Kurt pointed out in another (?) thread "CRAN is not the R
universe", and, e.g., Seth might have another opinion when it comes to
BioC administration. But I don't think you can (or should) do too much
sensible computations on packages without having parsed the
DESCRIPTION file, so the "almost no cost" statement should be pretty
safe.
> And, BTW, Gabor, NEWS and ChangeLog are not at all the same
> thing and it would be silly to urge users to one of them.
> At least 'ChangeLog' is a well defined format for emacs users
> that can very quickly be updated semi-automagically
> ("C-x 4 a" when you're in file foo.R with function myfun(.)
> autogenerates a neat entry in a ChangeLog file);
> but then really people should be allowed to use other formats
> for good reasons.
I fully agree.
.f
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem Sweaving vignettes: MiKTeX's texi2dvi reports errors
> On Mon, 3 Oct 2005 11:31:40 -0400, > Gabor Grothendieck (GG) wrote: > I have R installed in c:\Program Files\R and I use MiKTeX and texi2dvi > to process my vignettes. I do keep my package sources elsewhere; > e.g. I would keep the source for mypkg in c:\Rpkgs\mypkg . > and I would install it into c:\Rpkg\library or once I am ready to use it > in production into e.g. c:\Program Files\R\rw2011pat\library > thus I don't think its necessary to relocate R itself. The problem is the path to the *style file* sitting in $RHOME/share/texmf, so having the packages in a different place has nothing to do with it. It is also not really necessary to relocate R itself, you just have to move the style file to some place where latex finds it (e.g., by including $RHOME/share/texmf in your TEXINPUTS path ... but that will make troubles when the path contains spaces and we are back at the beginning). .f __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem Sweaving vignettes: MiKTeX's texi2dvi reports errors
>>>>> On Mon, 3 Oct 2005 16:30:24 +0100 (BST),
>>>>> Prof Brian Ripley (PBR) wrote:
> On Mon, 3 Oct 2005, Peter G. Warren wrote:
>> Hi, Prof. Ripley,
>>
>> Yes, indeed, that was my problem - thank you! I made the mistake of
>> installing in the default path of C:\Program Files\R. I just now
reinstalled
>> in C:\R, and everything worked fine. However, if anyone else runs into
this,
>> you cannot just go off and run texi2dvi on an existing .tex file after
>> installing in a non-space path: you should rerun the whole Sweave example,
>> which forces a number of additional required items to be downloaded.
> Indeed as the path is hardcoded in the .tex file generated by Sweave. In
> my case
> % -*- mode: noweb; noweb-default-code-mode: R-mode; -*-
> \documentclass[a4paper]{article}
> \title{A Test File}
> \author{Friedrich Leisch}
> \usepackage{a4wide}
> \usepackage{d:/R/svn/trunk/share/texmf/Sweave}
>> Let that process complete, then rerun again. It works fine! The finished
>> pdf file sure looks sweet.
> Good. We should try to fix this at R level if we can. To Fritz Leisch: I
> presume this is coming from RweaveLatexSetup's
> if(stylepath){
> styfile <- file.path(R.home("share"), "texmf", "Sweave")
> if(.Platform$OS.type == "windows")
> styfile <- gsub("", "/", styfile)
> if(any(grep(" ", styfile)))
> warning(gettextf("path to '%s' contains spaces,\n", styfile),
> gettext("this may cause problems when running LaTeX"),
> domain = NA)
> }
> else
> styfile <- "Sweave"
Yes.
> So, there should have been a warning that seems not to have been seen.
> However, if we added the opposite of normalizePath() to form the short
> path, would that fix this?
Actually, thinking about it again makes me wonder if the best solution
isn't to simply copy the few lines I need to the .tex file if no
\usepackage[...]{Sweave} is found.
Too late for 2.2.0 but I would consider the problem a bug, so could
try to fix it for 2.2.1.
Best,
Fritz
--
---
Friedrich Leisch
Institut für Statistik Tel: (+43 1) 58801 10715
Technische Universität WienFax: (+43 1) 58801 10798
Wiedner Hauptstraße 8-10/1071
A-1040 Wien, Austria http://www.ci.tuwien.ac.at/~leisch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CRAN mirror at StatLib
Dear Pantelis,
there have been numerous reports on the R mailing lists that the
StatLib mirror of CRAN is not up to date, and I also have written
several emails to you asking about the nature of the problems. E.g.,
http://lib.stat.cmu.edu/R/CRAN/bin/windows/contrib/
shows an old listing, and
http://lib.stat.cmu.edu/R/CRAN/bin/windows/contrib/r-release/
points to the wrong directory giving packages for the development
version of R rather then the released version (on the master it is a
link to 2.2, on your copy it seems to be a link to 2.3).
If the problems persist and cannot be fixed it is perhaps the easiest
solution if you stop mirroring CRAN, as download problems from StatLib
get reported to us as "bugs in R".
With best regards,
Fritz Leisch
--
---
Friedrich Leisch
Institut für Statistik Tel: (+43 1) 58801 10715
Technische Universität WienFax: (+43 1) 58801 10798
Wiedner Hauptstraße 8-10/1071
A-1040 Wien, Austria http://www.ci.tuwien.ac.at/~leisch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] StatLib mirror now OK
Pantelis Vlachos (the StatLib admin) and I figured out what the problems with the CRAN mirror on StatLib were and he seems to have fixed all problems in the mirroring process. Please let us know if you still observe problems with the StatLib mirror. Best, -- --- Friedrich Leisch Institut für Statistik Tel: (+43 1) 58801 10715 Technische Universität WienFax: (+43 1) 58801 10798 Wiedner Hauptstraße 8-10/1071 A-1040 Wien, Austria http://www.ci.tuwien.ac.at/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Citation of R packages
>>>>> On Mon, 30 Jan 2006 10:06:52 +1100 (EST), >>>>> John Maindonald (JM) wrote: > The bibtex citations provided by citation() do not > work all that well in cases where there is no printed > document to reference: That's why there is a warning at the end that they will need manual editing ... IMHO they at least save you some typing effort in many cases. > (1) A version field is needed, as the note field is > required for other purposes, currently trying to > sort out nuances that cannot be sorted out in the > author list (author, compiler, implementor of R version, > contributor, ...) and maybe giving a cross-reference > to a book or paper that is somehow relevant. Why should a reference cross-reference another reference? Could you give an example? > (2) Maybe the author field should be more nuanced, or > maybe ... author fields of bibtex entries have a strict format (names separated by "and"), what do you mean by "more nuanced"? > (3) In compiling a list of packages, name order seems > preferable, and one wants the title first (achieved by > relocating the format.title field in the manual FUNCTION > in the .bst file > (4) manual seems not an ideal name for the class, if > there is no manual. A package always has a "reference manual", the concatenated help pages certainly qualify as such and can be downloaded in PDF format from CRAN. The ISBN rules even allow to assign an ISBN number to the online help of a software package which also can serve as the ISBN number of the *software itself* (which we did for base R). > Maybe what is needed is a package or suchlike class, > and several alternative .bst files that handle the needed > listings. > I know at least one other person who is wrestling with > this, and others on this list must be wrestling with it. I am certainly open for discussions and any suggestions for improvements, but it must be within the standard bibtex entry types, we cannot write our own entry types and .bst files. Many journals require the usage of their own (or standard) bibtex styles, and the entries we produce must work with those. If R creates nonstandard bibtex entries even more manual work will be necessary in many cases. I have no definitive bibtex reference at hand, but the natbib style files (a very popular collection of bibtex styles, at least I definitely want to be compatible with those) define article book booklet conference (= alias for inproceedings) inbook incollection inproceedings manual mastersthesis misc phdthesis proceedings techreport unpublished which coincide with the choices the emacs bibtex mode offers. Out of these only "manual", "misc" and "unpublished" seem appropriate for packages, and the description suggests to use manual for citing software manuals, but the definitions of those three are very similar anyway. Maybe you could give an example what your candidate for a bibtex entry for packages should look like? Best, Fritz -- --- Friedrich Leisch Institut für Statistik Tel: (+43 1) 58801 10715 Technische Universität WienFax: (+43 1) 58801 10798 Wiedner Hauptstraße 8-10/1071 A-1040 Wien, Austria http://www.ci.tuwien.ac.at/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] What about a bib file
> On Mon, 30 Jan 2006 17:49:37 -0500 (EST), > Vincent Carey 525-2265 (VC5) wrote: > Romain Francois suggests that a central bibliographic database > (possibly in bibtex format) might be useful for reference inclusion > in R package man pages. This has been discussed by a small > group, with one proposal presented for a package-specific bibtex database > placed in a dedicated package subdirectory. Man page references would > then cite the sources enumerated in the database using their bibtex > tags. This approach could encourage better annotation and should > confer greater accuracy on package:literature referencing. > This does not rule out a central archive that might include all the > references cited in base man pages. > We are doing some work on harvesting the bibliographic citations > in man pages in an R distribution, and converting them to a regular > format. The \references section is free form, so the conversion > is not trivial, but progress has been made. > The infrastructure required to use this approach to propagate > (e.g., bibtex-formatted) bibliographic data into the man pages that > cite the sources is not yet available, but we hope to have some > prototypes in the next month. Sounds great! The "hardest" parts are probably 1) a bibtex parser in R 2) at least one function converting arbitrary bibtex entries to text, i.e., the R equivalent of a .bst file. (I'm only guessing what such a system would involve). After looking into it when writing the citation() infrastructure I decided I don't want to do it and went straight to S objects written by the package author. All those string replacements and possible LaTeX markup simply looked like too much effort for just 1-2 entries per package ;-) But it would be great to have the above functionality in R, of course, and "all references" in a package are certainly a larger set then what citation() should report, making the effort worthwhile. My only wish is that the bibtex parser returns objects compatible to class "citation" (either the same class or simple coercion). I modelled the class after bibtex entries anyway, so that shouldn't be a restriction (I hope). If we need to modify class "citation" to be accomodate your needs, please let me know. Once we can suck bibtex files into R it would be trivial to give users a choice between writing CITATION files in the current form (with the benefit of headers and footers) or mark certain entries in the PACKAGE.bib file (whatever its name may be) that they should be reported by citation(). Best, Fritz PS: Of course I volunteer to alpha-test any prototypes you have, __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN down ?
> On Fri, 5 Jul 2019 11:45:41 -0500, > Dirk Eddelbuettel (DE) wrote: > There seems to be another outage of the Vienna CRAN server [1] though from > what I can from afar not related to DNS outage [2]. > Could anyone confirm and possibly alert the local team in Vienna? Seems to work fine for me, both http and ping from non-WU machines (but of course from Vienna): leisch@nona01:~$ ping cran.r-project.org PING cran.wu-wien.ac.at (137.208.57.37) 56(84) bytes of data. 64 bytes from cran.wu-wien.ac.at (137.208.57.37): icmp_seq=1 ttl=58 time=1.43 ms 64 bytes from cran.wu-wien.ac.at (137.208.57.37): icmp_seq=2 ttl=58 time=1.22 ms 64 bytes from cran.wu-wien.ac.at (137.208.57.37): icmp_seq=3 ttl=58 time=1.62 ms 64 bytes from cran.wu-wien.ac.at (137.208.57.37): icmp_seq=4 ttl=58 time=1.47 ms Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] broken link to new features in R-devel: no NEWS file
>> Prof Brian Ripley >> on Wed, 21 Jul 2010 07:27:58 +0100 (BST) writes: > > > Please report problems with websites to the webmaster: no > > one else can handle them. I believe that for CRAN the > > appropriate address is cran-ad...@r-project.org. > > In addition, please let me note that one of the very oldest > "website"s for R *developement* has been > > http://stat.ethz.ch/R-manual/ (used to be called "R-alpha") > > it contains manuals of both "R patched" and "R manual" > *and* direct links to the "NEWS" of both. > Original problem now fixed on CRAN. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to set up an own package repository
>>>>> On Fri, 17 Sep 2010 12:16:47 +0200, >>>>> Janko Thyson (JT) wrote: > Dear List, > I'd like to set up a package repository so I can use install.packages() on > it for home-grown packages. I set up an AMPP infrastructure on a windows box > already, but I'm pretty lost with respect to what to do next as I didn't do > any web-programming/admin yet. Could anyone recommend some r-specific > tutorials or has a couple of suggestions for me? I've had a look at the > official R manual, but it just describes the required repository structure, > but not how to implement that. I'd also be willing to dive into SVN and > alikes if you think that's best practice. If all machines involved can mount the repository as a network drive you need no webserver at all, just use a file:/path/to/repository URL for the repository. If you want a full featured web frontend you may want to have a look at the Bioconductor scripts for generating repositories: http://bioconductor.org/packages/2.7/bioc/html/biocViews.html and especially http://bioconductor.org/packages/2.7/bioc/vignettes/biocViews/inst/doc/createReposHtml.pdf The scripts for CRAN are also in R but very specific for CRANs needs ... Best, Fritz -- --- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.statistik.lmu.de/~leisch --- Journal Computational Statistics --- http://www.springer.com/180 Münchner R Kurse --- http://www.statistik.lmu.de/R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] My retraced version of R logo in SVG
Dear Tobias, thanks a lot, this looks very nice. I just exported it to PDF and can zoom in and out with great results. I think we should replace the current logo with bitmaps (where necessary) of your version and would the be able to use vector versions wherever possible. Great work & really appreciated! Best, Fritz > Salvete, > > when over the the weekend I found myself incapable of looking at any > more numbers and code, seeing the R logo, I wondered how one would go > about replicating the old-fashioned faux 3D effects it uses. > > I thought it would make for a good distraction and exercise to try and > mimic it in SVG as close as possible, tracing the simple shapes by hand > and using layered gradients. > > This is the result: > > http://www.alice-dsl.net/~towolf/rlogo/Rlogo-novo.svg > > for comparison, this is the PNG logo at the same size > > http://svn.r-project.org/R-dev-web/trunk/Logo/Rlogo-2.png > > The SVG is stripped down to 80K and the PNG is 200K. > > I also have a version with preserved Inkscape metadata at 140K and a 2K > versoin with only the two flat shapes: > > http://www.alice-dsl.net/~towolf/rlogo/Rlogo-novo-editable.svg > http://www.alice-dsl.net/~towolf/rlogo/Rlogo-simple.svg > > I thought someone might find a use for these. If yes, just go ahead. > Itâs easy to edit these files. Change the color, make them prettier, or > more physically plausible in terms of shading. I just put them under > cc-by-sa. > > --Tobias > > __ > 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] Vignette Questions
> Dear List,
>
> I recently stumbled over the possibility and need to specifiy
> % \VignetteDepends{}
> in my vignettes. I did not know about this, and I notice that it is not
> mentioned in the R-extensions manual section "Writing package vignettes".
> [...]
Very strange, both Kurt Hornik and myself could have sworn that this has
been documented. But of course you are right that it currently is not and
clearly should be. I will have a shot later this week.
Best regards,
Fritz Leisch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] embed Sweave driver in .Rnw file
> On Tue, 14 Dec 2010 12:40:04 +0100,
> Romain Francois (RF) wrote:
> Hello,
> Sweave lets you use alternative drivers through the driver argument, and
> several packages take advantage of that and define custom Sweave driver
> for various purposes. Most of them are listed on the Reproducible
> Research CTV:
> (http://cran.r-project.org/web/views/ReproducibleResearch.html)
> The next natural step is for package developpers to take advantage of
> this in their vignettes. In Rcpp we work around the way package building
> works and we do:
> - let R build a dummy vignette
> - then use the inst/doc/Makefile to replace it with a vignette that is
> processed by the driver from the highlight package (giving syntax
> highlighting).
> I played with Sweave so that it would be able to create the driver from
> some text included in the text of the .Rnw file:
> $ svn diff
> Index: src/library/utils/R/Sweave.R
> ===
> --- src/library/utils/R/Sweave.R(revision 53846)
> +++ src/library/utils/R/Sweave.R(working copy)
> @@ -20,6 +20,16 @@
> # We don't need srclines for code, but we do need it for text, and
> it's easiest
> # to just keep it for everything.
> +SweaveGetDriver <- function(file){
> +txt <- readLines(file)
> +line <- grep( "\\SweaveDriver", txt, value = TRUE )
> +if( length(line) ){
> +txt <- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L] )
> +driver <- try( eval( parse( text = txt ) ), silent = TRUE )
> +if( !inherits( driver, "try-error") ) driver
> +}
> +}
> +
> Sweave <- function(file, driver=RweaveLatex(),
> syntax=getOption("SweaveSyntax"), ...)
> {
> @@ -28,7 +38,9 @@
> else if(is.function(driver))
> driver <- driver()
> -
> +drv <- SweaveGetDriver(file)
> +if( !is.null(drv) ) driver <- drv
> +
> if(is.null(syntax))
> syntax <- SweaveGetSyntax(file)
> if(is.character(syntax))
> This allows one to write something like this in their file:
> %\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }
> So that when calling :
>> Sweave( "somefile.Rnw" )
> the highlight driver is used instead of the default driver.
> Could something like that be added to Sweave ?
Yes, sure!
Will have a look at the patch later this week and apply it if it
passes the tests. The patch is against a current r-devel?
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Set up new CRAN mirror; but have questions before finalizing.
> On Fri, 18 Feb 2011 22:00:28 -0600, > Paul Johnson (PJ) wrote: > Hi, everybody > I have an account on Dreamhost.com and when I renewed it recently, > their message said my usage of storage and bandwidth had been > reasonably low. In an idle moment about 3 weeks ago, I followed your > instructions to set up a CRAN mirror on their server. Here it is: > http://www.freefaculty.org/cran > It is not hosted at my University, but it is a working, high > availability server. Is there any reason it could not be listed as a > CRAN mirror. (Although I really have no idea where these machines > exist. I'm pretty sure it is in the USA. I'll try to find out). We would need to know where it is because we lsit mirrors in the US sorted by state ... > Maybe you might try it and see? It has updated several times, no > trouble I can see in that. > I have a couple of small details to ask about. Maybe this first one > is a potential "bug report" for the CRAN mirror instructions. > 1. Permissions on "src" and "web" folders are 700, Then you must have made a mistake in setting up the mirror, because on the master we have 775 for both directories and all directories within these two. We also had never complaints about this before. > and so running "update.packages" or an apt-get update against the > debian stuff results in permission denied errors. I re-set the > permissions manually, but wonder if I'm actually supposed to mess > around with your archive. After doing that, it works. But I > worry a little bit about what else might not be readable "down > there" in the hierarchy. And I wonder why any body else's mirror > works without doing that. Well, they simply mirrored our permissions ... > 2. When I run "apt-get update" against my mirror, i get a lot of > harassment about the lack of a security key for my repository. Should > I be publishing an R Core team key to fix that, or my own key to do > what? I've never administered an apt repository before. I have > administered yum repositories and the security there is in the key on > the individual RPMS, I don't quite understand what the Debian thing is > asking me to do. It is quite common then non-official Debian mirrors have no security key, I would not worry too much about that. Best regards, Fritz Leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Conditional "Suggests"
> On Mon, 11 Apr 2011 13:30:24 -0700, > Geoff Jentry (GJ) wrote: > On Mon, 11 Apr 2011, Hadley Wickham wrote: >>> To me this reads as being in the wheelhouse of what 'Suggests' is supposed >>> to imply, as per the R Extensions manual. The problem here is that if PkgB >>> is put down as 'Suggests', it is required for R CMD check to pass which >>> seems to defeat the purpose of this exercise a bit. >> No, because R CMD check is only run by the developer, not the user. > It's not only run by the developer, it's also run by CRAN. The situation > might happen where for a particular platform (e.g. Windows) that PkgB > doesn't exist. It'd be nice to be able to avoid a situation where PkgA > can't exist for that platform simply because PkgB - which isn't even > necessarily required for PkgA to be used - doesn't exist for it. That is not the case, the checks will only get a NOTE that PkgB doesn't exist. E.g., my package flexclust suggests multicore, which is not available for windows. Still both live happily on CRAN, and of course there is a windows version of flexclust available from CRAN. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave tokens not in column 1: enhancement request
> On Tue, 19 Apr 2011 13:59:44 -0700 (PDT),
> David Epstein (DE) wrote:
> When I re-use a code chunk in Sweave, together with keep.source=TRUE, I
would
> like to follow usual programming conventions in which the amount of white
> space on the left indicates logical structure. It seems that one can't do
> this in Sweave, or am I wrong?
> for (i in ind) {
> do such-and-such and then
> <>
> do something-else
> }
> Sweave will say that << is an error. Would it be difficult to change Sweave
> so that formatting in the conventional way becomes possible? I'm thinking
> both of the .Rnw file and of the final output in the .pdf or .ps file.
Not difficult at all, that's a trivial change:
MySyntax <- utils::SweaveSyntaxNoweb
MySyntax$coderef <- "^[[:space:]]*<<(.*)>>.*"
Sweave("test.Rnw", syntax=MySyntax)
should do what you want. That code references need to start in column 1
is inherited from noweb, not sure if we really need it. Cannot think
of a situation where the above regular expression appears in valid R
code, but perhaps I am overlooking something.
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Creating XML document extremely slow
> On Fri, 10 Feb 2012 13:18:38 +0100, > Titus von der Malsburg (TvdM) wrote: > Hi list, > I'm using the package XML to create a simple XML document. > Unfortunately constructing the XML tree is extremely slow. My code > (see below) adds only about 100 nodes per second on an Intel i5 > machine. There's clearly something wrong but I don't see what. Have you considered simply writing the XML using standard functions like cat() and friends? That can be much faster than creating an XML object and writing that out (have just done that to write exams into our e-learning platform via XML). Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] French Toulouse CRAN mirror always down
> On Fri, 28 Sep 2012 09:37:39 +0200, > Milan Bouchet-Valat (MB) wrote: > Hi! > One of the three French CRAN mirrors, cran.cict.fr (Toulouse) seems to > be down most of the time, and at least really not reliable. It has > currently been down for 28 days (!) [1], and I know that over two years > I've rarely been able to use it (no response, slow, hangs...). > I'm sure the maintainers of this mirror mean well, but the result is > really negative for French R users. This week I observed one user that > failed to install a package because she selected that mirror and it was > not available. Such a minor detail can give a very poor impression to > beginners. > I suggest that either the maintainers of this mirror explain why it does > not work and provide solutions to improve the situation, or it should be > removed from the list until it works reliably. Not as a punishment of > course, but for practical considerations. > At the very least this mirror should be moved down the list: at the > moment it's the first of the three French mirrors, while the two others > work very well. If the mirrors were sorted by the alphabetical order of > their full names, it would be the last one, and it would be bite French > users less often, while still acting as a fallback solution. It has already been removed a couple of days ago, have a look e.g. at http://cran.r-project.org/mirrors.html will need some time to propagate to all places. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] different results on linux and windows
>>>>> On Tue, 12 May 2009 13:30:21 +0300, >>>>> Klaus Nordhausen (KN) wrote: > Dear R experts, > we are preparing an R-package to compute the Oja Median which contains > some C++ code in which random numbers are needed. To generate the random > numbers we use the following Mersenne-Twister implementation: > // MersenneTwister.h > // Mersenne Twister random number generator -- a C++ class MTRand > // Based on code by Makoto Matsumoto, Takuji Nishimura, and Shawn Cokus > // Richard J. Wagner v1.0 15 May 2003 rjwag...@writeme.com > the random seed for the Mersenne-Twister is provided by our R-function > which gives an (random) integer to the C++ function srand() which in > turn sets the seed in the code. > Using the set.seed in R makes now the results reproducible, but the > results differ between windows and linux. > Does anyone know what the problem there is? [...] I cannot directly help with the problem, but one quick question: Why do you ship your own random number generator rather than use the one that ships with R (which by default is Mersenne Twister anyway)? The API is documented in "Writing R Extensions". The advantage in using R's RNG is that the user can change it, e.g., to take care of streams for parallel processing on clusters etc Best, Fritz -- --- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.statistik.lmu.de/~leisch --- Journal Computational Statistics --- http://www.springer.com/180 Münchner R Kurse --- http://www.statistik.lmu.de/R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] improving ?RweaveLatex
> On Sat, 22 Aug 2009 16:51:31 -0500, > Marc Schwartz (MS) wrote: > > On Aug 22, 2009, at 4:30 PM, Marc Schwartz wrote: >> >> I have some proposed modifications to RweaveLatex.Rd which I include >> here as a patch against the R-devel version of the file from svn. I >> have added comments about the issue that Liviu raised, the use of >> the [nogin] option and while I was at it, the [noae] option as well. >> There are added to the 'details' section of the file. > OK, once more > I noted a typo and also neglected to add pointers to the Details > section in the descriptions of the height and width options. > Here is a corrected version of the patch file. Thanks a lot, will apply the patch in a minute. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: Allow packages to add additional information to sessionInfo()
> On Thu, 3 Sep 2009 11:10:31 -0700, > Henrik Bengtsson (HB) wrote: > On Thu, Sep 3, 2009 at 10:38 AM, Kevin R. > Coombes wrote: >> [1] I agree that sessionInfo() can be taken further. >> [2] I even more strongly agree that it would be a bad idea to allow packages >> to add features that cause the base sessionInfo() function to fail. >> >> Why not add an extra function called something like "packageSessionInfo()" >> that would provide the desired hooks but keep them from breaking the base >> functionality? > The point is that (if so) there should only be *one function* to call > for all packages, not one per package, because that would be a pain > due to dependencies. But, sure I'm happy to start with a > package[s]SessionInfo() such that > c(sessionInfo(), extras=packagesSessionInfo()) > pretty much return what I wish. Then it might be easier to argue for > incorporating the above in sessionInfo() ;) > Sorry for not getting it, but I still don't see how adding extra > information would break the base functionality? Can you give some > examples? > As I said, timeouts can be a problem and possibly also if the hook > functions have side effects that, say, would load new packages, could > give funny results, but I also think a package developer who is > capable to setting up hook function would no how to avoid this. > With the default argument of 'extras' to be FALSE, sessionInfo() would > work as now, with the extra feature that 'extras=TRUE' can give lots > of additional useful information. I think the concept of hook functions for sessionInfo() makes absolute sense. Yes it should be optional to run them, but the default should be pkghooks=TRUE, because I don't see why they shouldn't run OK in 99.9% of all cases. If a hook doesn't run on a certain platform that would be a bug to me and need to be fixed. Could those who seem to think such hooks are not a good idea elaborate on what the "danger" really is? Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check: Error in .C
[ Note that this discussion really belongs to r-help, not r-devel, but
a nyway.
>>>>> On Tue, 27 Oct 2009 09:02:12 +1300,
>>>>> Etienne Laliberté (EL) wrote:
> Many thanks Mathieu, following your answer I did a bit more focused
> research and found out that because "mypackage" had a NAMESPACE, I had
> to create the following zzz.R file instead:
> .onLoad <-function (lib, pkg) {
> library.dynam("mypackage", pkg, lib)
> }
If you have a namespace you only need a
useDynLib(mypackage)
in the NAMESPACE file, everything else is done automatically for you
(no need for the above zzz.R).
Best,
Fritz
--
-------
Prof. Dr. Friedrich Leisch
Institut für Statistik Tel: (+49 89) 2180 3165
Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308
Ludwigstraße 33
D-80539 München http://www.statistik.lmu.de/~leisch
---
Journal Computational Statistics --- http://www.springer.com/180
Münchner R Kurse --- http://www.statistik.lmu.de/R
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Removing cran mirrors
> On Tue, 3 Nov 2009 09:46:11 -0600, > Hadley Wickham (HW) wrote: >> Fritz does that from time to time. Note that this is always rather >> cumbersome: trying to contact maintainers whose addresses do not exist any >> more and so on. > I'd be more draconian - if the mirror doesn't update for two weeks, > just cut it off automatically. If they want to get back on the list, > it's their problem. It shouldn't be Fritz's problem! Well, then we would have to create "two classes" of mirrors: If ETH Zürich goes down I'd prefer to inform Martin Mächler that there is a problem rather than cutting off automatically (same for a lot of others). But note that the list of "monitored mirrors" is a superset of the list of "listed mirrors": The first real problem mirror.cricyt.edu.ar is not in the list of mirrors at http://cran.r-project.org/mirrors.html (and what you get when you are online and select a mirror via GUI). Same for all the other very bad ones. It is a simple Flag "use mirror" in the master table, which is used both by R itself and the scripts creating the webpages (which run fully automated). Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion for the reproducibility of R home page figure
Thanks a lot, fixed. Best, Fritz > On Fri, 20 Nov 2009 19:53:31 +0100, > Jean lobry (Jl) wrote: > Dear R-devel, > googling for the single letter R yields R-home page as the firt hit, > which is extremly nice. > By clicking on the figure you get the code of the "Winner of the R > Homepage graphics competition 2004." > By copy/pasting in your R console it doesn't work because it is impossible > to install the mva package. > This is my point. > As documented in ONEWS the reason is simple: since R 1.9.0 the package > mva as been merged into the package stats. > My suggestion is just to change the begining of the code as follows to > neutralize the requirement for the mva package: > > ### Code by Eric Lecoutre, Universite catholique de Louvain, Belgium > ### Winner of the R Homepage graphics competition 2004 > ### Works in R 1.8.1 ... > ### Still works in R 2.10.0 (2009-10-26) by deleting the requirement > for the mva package ... > require(ade4) > #require(mva) no more needed since R version 1.9.0 as mva was merged > in the standard stats package. > require(RColorBrewer) > require(pixmap) > etc. > > so that reproducibility of the graph is straightforward (at least for > someone who > is able to install an R package). > This is a minor change. I consider this is important because it may help people > wanting to test quickly the long term reproducibility of R results. For them > installing a package is not a problem, but do not expect them to have time to > dig in old ONEWS > Please take this as a constructive comment, I was amazed how it was easy for me > to run this "old" R code. Just want to share. > Very Best, > Jean > -- > Jean R. Lobry(lo...@biomserv.univ-lyon1.fr) > Laboratoire BBE-CNRS-UMR-5558, Univ. C. Bernard - LYON I, > 43 Bd 11/11/1918, F-69622 VILLEURBANNE CEDEX, FRANCE > allo : +33 472 43 27 56 fax: +33 472 43 13 88 > http://pbil.univ-lyon1.fr/members/lobry/ > __ > 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] Flexclust barchart issue when mcol=NULL
> On Wed, 16 Dec 2009 07:05:11 +0100 (CET), > christopher a hane (cah) wrote: > Full_Name: Chris Hane > Version: 2.10.1 > OS: Windows > Submission from: (NULL) (198.203.181.181) > When using barchart in the flexcust package, setting mcol=NULL to avoid the > lollipops causes an error. Each panel shows the text message "Error using > packet n replacement has length zero." where n is the panel number. >> data(iris) >> cl <- cclust(iris[,-5], k=3) >> barplot(cl, mcol=NULL) #works fine >> barchart(cl, mcol=NULL) # oops Yes, that's a bug in flexclust. I'll fix it for the next release. In the meantime you can use barchart(cl, mcol=NA) which has the same effect for me. > FWIW, as the data of the clusters is scaled showing the colMeans > for the centers is misleading. The global mean of each column is > 0, not the colMean of the centers. Hmm, I am not sure I understand this paragraph. I agree that showing the global mean makes no sense for centered data, but the iris data are not centered. I don't think that barcharts like the above make sense in all possible situations. I mainly use them for binary data where I want to see which variables have a high/low percentage of ones in which cluster (=bars), and what the difference to the global mean is. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] wiki down?
>>>>> On Thu, 14 Jan 2010 11:45:31 -, >>>>> Matthew Dowle (MD) wrote: > I see the same problem. The wiki link on the R homepage doesn't seem to > respond. > A search of r-devel for subjects containing "wiki" finds this seemingly > unanswered recent post. > Is it known? Philippe Grosjean maintains the Wiki, in CC. Best, Fritz -- ------- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.statistik.lmu.de/~leisch --- Journal Computational Statistics --- http://www.springer.com/180 Münchner R Kurse --- http://www.statistik.lmu.de/R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [SoC] R and Google Summer of Code 2010: Call for Proposals
> On Tue, 23 Feb 2010 22:27:46 -0600, > Dirk Eddelbuettel (DE) wrote: > On 23 February 2010 at 22:06, hadley wickham wrote: > | > So let us all start now by proposing some ideas for 2010. It may make sense > | > to centralize and standardize this on wiki.r-project.org but until we have > | > that process sorted out lets just post ideas here on r-devel with a [SoC] tag > | > in the Subject: line. > | > | One idea per email? > Sure, works as a start. Or mayb better as one wiki.r-project.org entry per > idea because then we can all edit these rather having to noodle through > emails. But I am unsure where to 'hang this' in the wiki namespace. We > could also create a one-off at wikispaces.com or wikidot.comIf you have > another scratch wiki somewhere I think wiki.r-project.org would be a great place, I'd "hang it" into the developers section. Then we could have a look at GSoC 2010 ideas when GSoC 2011 arrives ... Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in Stangle(split=TRUE)
>>>>> On Sat, 07 Apr 2007 07:56:40 -0400, >>>>> Roger Peng (RP) wrote: > [I originally emailed this to Friedrich Leisch but got no response Sorry, was on easter vacation and have not fully suceeded to go through all mails in my inbox yet. > and I > just wanted to make sure it made it in before release.] > While working with Stangle(), I noticed a problem when using 'split = > TRUE'. Particularly, when there are two chunks where one chunk's name > is a prefix of another chunk's name, then the two chunks will be written > to a single file rather than two separate files (if the chunk who's name > is a prefix comes after the other chunk). Running 'Stangle(split=TRUE)' > with the attached 'test1.Rnw' file should reproduce the problem. > I think it boils down to a partial matching problem in 'RtangleRuncode'. > I've attached a patch against R-alpha (r41020) which I think fixes > this problem but I'm not sure it's necessarily the best approach (there > are other instances of this construction in the code). Same bug was also affecting Sweave. Fixed in the 2.5 and 2.6 branches, thanks a lot for the report. Best, Fritz __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build fails with try(stop()) in vignette
> On Wed, 11 Apr 2007 17:28:31 -0500 (CDT),
> Luke Tierney (LT) wrote:
> It would appear that printing the error message to stderr() is what is
> causing the build to fail; replace
> try(stop('err'))
> with
> cat('Error in try(stop("err")) : err\n', file = stderr())
> and I get the same failure.
Yes, both R CMD check and R CMD build "analyse" the textual output
from running R (on examples, vigenttes, ...) to locate
problems. Reason is a chicken&egg problem: You cannot use the same R
process which runs the code to spot all problems, because it may not
survive until the point where you are able to spot the problem.
Having errors thrown in code chunks is still in many ways an open
problem in Sweave files, because it is hard to distinguish problems
the user wants to show to the reader from ones that are not deliberate
...
Best,
Fritz
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build fails with try(stop()) in vignette
>>>>> On Thu, 12 Apr 2007 07:35:28 -0500 (CDT),
>>>>> Luke Tierney (LT) wrote:
> On Thu, 12 Apr 2007, Friedrich Leisch wrote:
>>>>>>> On Wed, 11 Apr 2007 17:28:31 -0500 (CDT),
>>>>>>> Luke Tierney (LT) wrote:
>>
>> > It would appear that printing the error message to stderr() is what is
>> > causing the build to fail; replace
>>
>> > try(stop('err'))
>>
>> > with
>>
>> > cat('Error in try(stop("err")) : err\n', file = stderr())
>>
>> > and I get the same failure.
>>
>> Yes, both R CMD check and R CMD build "analyse" the textual output
>> from running R (on examples, vigenttes, ...) to locate
>> problems. Reason is a chicken&egg problem: You cannot use the same R
>> process which runs the code to spot all problems, because it may not
>> survive untilthe point where you are able to spot the problem.
>>
>> Having errors thrown in code chunks is still in many ways an open
>> problem in Sweave files, because it is hard to distinguish problems
>> the user wants to show to the reader from ones that are not deliberate
>> ...
> Just to clarify: this means for now the recommendation would be for
> authors of vignettes using try() to arrange to suppress the error
> message either by adding silent=TRUE to the call or setting the
> show.error.messages option to FALSE?
Yes. We should try to get a better system, but I'm not sure what that
should be (and definetely not for 2.5).
Most of the stuff is by Kurt, so we should wait for his opinion. If
you look at the R CMD check code you will see a lot of grep's for
"^Error", so merely inserting a blank before the error message may do
the trick, but we have no means to automate that yet.
.f
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dendrogram definition
> On Fri, 20 Apr 2007 14:46:33 -0700, > Deepayan Sarkar (DS) wrote: > Hi, > I'm trying to create a "grob" representing a dendrogram object (for > use as a legend with lattice), and I have a question regarding how a > "dendrogram" should be interpreted. Are they by definition binary > trees or can they in principle have more than two children? They can have more than 2 children, and class "dendrogram" supports this. However, as most trees are currently created using hclust, all examples have binary trees. E.g., example(dendrogram) d3e[[3]]=d3e attr(d3e,"members")=14 str(d3e) creates a tree with three branches in the root node (not all attributes are correct after that brute force operation, so plots will not look as nice as possible). Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: allow packages to advertise vignettes on Windows
> On Mon, 14 May 2007 20:58:11 -0400, > Duncan Murdoch (DM) wrote: > [ ... GUI stuff deleted ] I'm of course very much in favor of adding vignettes automatically to the GUI. > By the way, another way to expose vignettes is to have them > automatically added to the package help topic, with links in formats > that support them. I think we should do that too, but I don't know if > it'll happen soon. Umm, but there is already information in the package help, e.g., if I do help(package="flexmix") then the end of the page I get is ** Further information is available in the following vignettes in directory '/home/Leisch/lib/R/flexmix/doc': flexmix-intro: FlexMix: A General Framework for Finite Mixture Models and Latent Class Regression in R} (source, pdf) regression-examples: Applications of finite mixtures of regression models (source, pdf) ** They are also linked into the HTML page for the package I get after help.start(). Obviously one can do more (and the GUI thing is a very good idea, because Windows users will look there first), but it's not like there is nothing at all ... Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] HTML vignette browser
> On Fri, 1 Jun 2007 16:22:18 -0700,
> Deepayan Sarkar (DS) wrote:
> Hi,
> this is tangentially related to the recent discussion on vignettes.
> vignette() currently produces a listing of available vignettes, but
> these are not clickable. Since R has a browseURL() function, it seems
> natural to have a version that produces HTML with clickable links.
> Here's an attempt at that:
> source("http://dsarkar.fhcrc.org/R/vignette-browser.R";)
> browseVignettes()
> browseVignettes(package = "grid")
> etc. Perhaps some variant of this could be added to R.
> Comments welcome.
Looks good to me, and certainly something worth being added to R.
2 quick (related) comments:
1) I am not sure if we want to include links to the Latex-Sources by
default, those might confuse unsuspecting novices a lot. Perhaps
make those optional using an argument to browseVignettes(), which
is FALSE by default?
2) Instead links to .Rnw files we may want to include links to the R
code -> should we R CMD INSTALL a tangled version of each vignette
such that we can link to it? Of course it is redundant information
given the .Rnw, but we also have the help pages in several formats
ready.
.f
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] HTML vignette browser
>>>>> On Mon, 04 Jun 2007 11:52:51 -0700, >>>>> Robert Gentleman (RG) wrote: > Deepayan Sarkar wrote: >> On 6/4/07, Seth Falcon <[EMAIL PROTECTED]> wrote: >>> Friedrich Leisch <[EMAIL PROTECTED]> writes: >>>> Looks good to me, and certainly something worth being added to R. >>>> >>>> 2 quick (related) comments: >>>> >>>> 1) I am not sure if we want to include links to the Latex-Sources by >>>> default, those might confuse unsuspecting novices a lot. Perhaps >>>> make those optional using an argument to browseVignettes(), which >>>> is FALSE by default? >>> I agree that the Rnw could confuse folks. But I'm not sure it needs >>> to be hidden or turned off by default... If the .R file was also >>> included then it would be less confusing I suspect as the curious >>> could deduce what Rnw is about by triangulation. >>> >>>> 2) Instead links to .Rnw files we may want to include links to the R >>>> code -> should we R CMD INSTALL a tangled version of each vignette >>>> such that we can link to it? Of course it is redundant information >>>> given the .Rnw, but we also have the help pages in several formats >>>> ready. >>> Including, by default, links to the tangled .R code seems like a >>> really nice idea. I think a lot of users who find vignettes don't >>> realize that all of the code used to generate the entire document is >>> available to them -- I just had a question from someone who wanted to >>> know how to make a plot that appeared in a vignette, for example. >> >> I agree that having a Stangled .R file would be a great idea (among >> other things, it would have the complete code, which many PDFs will >> not). >> >> I don't have a strong opinion either way about linking to the .Rnw >> file. It should definitely be there if the PDF file is absent (e.g. >> for grid, and other packages installed with --no-vignettes, which I >> always do for local installation). Maybe we can keep them, but change >> the name to something more scary than "source", e.g. "LaTeX/Noweb >> source". >I would very much prefer to keep the source, with some name, scary or > not... I have no strong opinion eitehr way, just "source" may have a lot of people belive that is R code -> whatever "scary" name is chosen sounds good to me. I'll have a shot at installing the tangled code later this week (there is a holiday coming up on Thursday). .f __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] step() in sink() and Sweave()
>>>>> On Wed, 13 Jun 2007 16:43:32 +0300, >>>>> Jari Oksanen (JO) wrote: > On Wed, 2007-06-13 at 13:33 +0100, Gavin Simpson wrote: >> Dear Developers, >> >> This change also just bit me whilst updating Sweave documents for some >> computer classes. >> >> Is there a work-around that can be employed so that we get both the >> message() bits and the print() bits in the same place for our Sweave >> files? >> >> If not, is there any point in filing this as a bug in R? I see there >> have been no (public) responses to Jari's email, yet the change is >> rather annoying, and I do not see the rationale for "printing" different >> parts of the output from step() in two different ways. >> > I think this is a bug. You should not use message() with optional trace. > The template for the usage in step() is first > if (trace) message() > and later > if (trace) print() > If you specifically request printing setting trace = TRUE, then you > should not get message(). > Interestingly, message() seems to be a warning() that cannot be > suppressed by setting options. > This is so annoying that I haven't updated some of my Sweave documents. > It is better to have outdated documents than crippled documents. > You can handle this in sink(), but I don't know any trick for Sweave > (and it's a nuisance in sink() as well). The topic is on the agenda, but no released code yet. Hadley Wickham has code collecting all output, messages, warning etc that arise when an expression is evaluated which can be used in various places like sink or Sweave to solve this problem. We have already scheduled discussions for a workshop which we both attend in 3 weeks. Sorry for not replying to the original email. Best, Fritz -- --- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.stat.uni-muenchen.de/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NEWS file (was faqs)
> On Fri, 16 Nov 2007 10:20:36 + (GMT), > Prof Brian Ripley (PBR) wrote: > On Thu, 15 Nov 2007, Simon Urbanek wrote: >> >> On Nov 15, 2007, at 10:53 AM, Duncan Murdoch wrote: >> >>> On 11/15/2007 9:57 AM, Simon Urbanek wrote: On Nov 14, 2007, at 11:55 PM, Gabor Grothendieck wrote: > inst/NEWS would have the advantage of consistency with R itself > which also has a NEWS file. > I vote for NEWS for reasons above plus because that's what I use in my packages already ;). IMHO it should be installed automatically if present, i.e. it shouldn't be necessary to have it in inst/NEWS, just plain NEWS should suffice. >>> >>> And you're volunteering to make that change? >>> >> >> Yup, in R-devel now (43464). However, there are other candidate files >> as well and we don't do anything with the NEWS file just yet ... any >> further ideas? > We've recommended inst/NEWS for some time (some people are late to this > party), and tens of packages have it. However, a further tens of packages > have a top-level NEWS, and I would assume that (at least some of) the > authors were deliberately not installing it and so will now need to rename > it. > I think the writeup needs to make clear what happens if you have both NEWS > and inst/NEWS (some packages do). As most having both are by me I also checked the rest: In all cases on CRAN they are identical copies. I have a soft link in all my packages from inst/NEWS to top level (such that it gets installed, but it is also easily found in the sources). If we install the top-level NEWS file I would remove the link (but as Brian said, we've been there before). Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Sweave: Variables in code chunk headers
> On Sun, 02 Dec 2007 19:41:04 +,
> Michael Hoffman (MH) wrote:
> Duncan Murdoch wrote:
>> I put together a clunky way to handle that for a presentation last week;
>> it may be enough for you.
>>
>> I leave the Sweave options at their defaults, but I have code chunks
>> that affect the appearance, and I run those without echoing to switch
>> between a couple of formats. For example, I have some pages that
>> display one figure, and others that display two.
> That is a decent way of doing what I am suggesting. Probably too
> complicated to be worth it if I am just changing one variable.
>> One other thing that would have helped with this approach would be a way
>> to include another file: then I wouldn't have to repeat those
>> definitions in every Rnw of the project.
> Yet another candidate for (yet another) pre-processing step. :)
> Of course, you could load the complicated bits in another file with
> source(). You'd still have to redefine <> and <>
> everywhere, but at least you would be able to change the option settings
> easily. Like this:
> <>
> source("init.R")
> @
> <>=
> setup.single() # loaded from init.R
> @
Why do threads on Sweave always seem to happen when I am offline? ;-)
Sorry to join in late, but my excuse is rather good: A plane over
Siberia isn't exactly email-territory yet (at least in economy
class): I was in transit from Munich to Tokio for most of the last 20
hours.
I do have untested code which evaluates options rather than statically
processing them, but I don't want to commit that in my current state
of mind (and I know that it needs another round of testing). I'm also
not sure how good my internet connectivity will be for the rest of the
week -> next week at the latest. Perhaps I can also include Max'
suggestion of default settings via options() & styles a la odfWeave.
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Google summer of Code
As you may have noticed from a previous email the R Foundation has been accepted as a mentoring organization for the Google Summer of Code 2008, see http://code.google.com/soc/2008/ for general information and http://www.r-project.org/SoC08/index.html for our ideas page (which is still evolving a little bit). The R Foundation has not acted as a mentoring organization before, so everything is a little bit experimental for us (some R developers have participated before through other organizations). This email is mainly meant to inform you about the fact that we are in and encourage you to pass on the information to talented students who may want to participate (accepted students get a stipend of USD 4500 from Google when they successfully finish the project). Best, Fritz Leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Google summer of Code
>> The R Foundation has not acted as a mentoring organization before, >> so everything is a little bit experimental for us . . . > > Is R-devel an appropriate place for GSoC communication, Fritz? My > message specific to Roxygen went unanswered.* Sorry for that, I already asked Manuel (one of my assistants and mentor of the project) to answer your questions, but we are having network problems due to a broken switch in our building and most computers do not work (mine is one of the few exceptions ;-). We hope that everything is up and running again in a few hours. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [rd] sage <--> r integration
>>>>> On Thu, 17 Apr 2008 09:05:56 -0700, >>>>> Rob Goedman (RG) wrote: > Mike, > I'm also surprised so few reactions have been forthcoming. I saw > William's email shortly after Jan's email about Sage. There is a priovate mailing list for all R Google SoC mentors and parts were discussed there. > Having been involved in the Ryacas project (R to Yacas - Yet Another > Computer Algebra System - with Gabor, Soren and Ayal), I believe in > the tremendous benefits of such an integration and have, over the > last couple of days, been studying Sage and its notebook interface to > better understand how it could be used as an alternative/complement to > the current Mac R.app (having occasionally helped out Simon on the Mac > R GUI - R.app). > I am a firm believer in Python, and have worked on Python/ > Django/"Python on Embedded systems for biometrics" for well over 2 > years now. I do believe this is also a major benefit of Sage. And > projects such as Google's App Engine provide further support. > From Willliam's email I take it the best route right now is to try to > bring this project the attention of the GSoC mentors. Sorry, it is not a problem of "not enough attention". The problem is, that the R Foundation was assigned four slots by Google, and we have much more projects than 4, and cannot even fund all projects by R core members. If things stay the way they are only two of the four will be mentored by members of the core team, so it's not like we take all slots for us. If we fund the R-Sage project, I have to take somebody else his slot away. The decision is not "do we fund R-Sage or not", but which 4 of the 20+ applications do we choose. The decisions which projects to fund were based on factors like: 1) Quality of the student application, i.e., how much work of the student went into preparing the application, did he read into code or textbooks that can help, how much email exchange with the prospective mentor etc (most important) 2) How important is the project for R? 3) How much did the mentor contribute to R in the past? Number 3) looks like we don't like outsiders, but that is not the point. If we want to participate again next year, our number of slots will also be based on how successfull we are this year. And for mentors we know well it is easier to guess if they can meet their goals than for people unknown to us. This is of particular importance for writing interfaces between systems, where knowledge of R internals can be crucial. It is not like that I do not think that the project can be done by the people proposing it, but there are no means for me to assess in the limited time we have whether they can do it or not. I would love to assign slots to every projects that looks good, but Google gave us only four, so somebody has to be disappointed. But allmost all of R got created without any external funding, so I don't see why this should be stop for the project. It won't be me doing it, but I would be very excited to see it happen! Best, Fritz -- --- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.statistik.lmu.de/~leisch --- Journal Computational Statistics --- http://www.springer.com/180 Münchner R Kurse --- http://www.statistik.lmu.de/R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] k means
>>>>> On Mon, 12 May 2008 19:24:55 +0200, >>>>> cgenolin (c) wrote: > Hi the devel list, > I am using K means with a non standard distance. As far as I see, the > function kmeans is able to deal with 4 differents algorithm, but not > with a user define distance. > In addition, kmeans is not able to deal with missing value whereas > there is several solution that k-means can use to deal with them ; one > is using a distance that takes the missing value in account, like a > distance with Gower adjustement (which is the regular distance dist() > used in R). > So is it possible to adapt kmeans to let the user gives an argument > 'distance to use'? As Bill Venables already pointed out that makes not too much sense, especially as there are already R functions for doing that. Package flexclust implements a k-means-type clustering algorithm where the user can provide arbitrary distance measures, have a look at http://www.stat.uni-muenchen.de/~leisch/papers/Leisch-2006.pdf The code you need to write for using a new distance measure is minimal, and there are two examples in the paper describing in detail what needs to be done. Hope this helps, Fritz Leisch -- ------- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.statistik.lmu.de/~leisch --- Journal Computational Statistics --- http://www.springer.com/180 Münchner R Kurse --- http://www.statistik.lmu.de/R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] k means
>>>>> On Sat, 17 May 2008 00:54:55 +0200,
>>>>> cgenolin (c) wrote:
> Hi the list
> I try the flexclust, but I do not manage to see what is wrong in my
> (very simple) code...
> Will you have few minutes to check it?
> Thanks for your help.
> Christophe
> --- 8<
> data <- rbind(c(1,2 ,NA,4 ),
>c(1,1 ,NA,1 ),
>c(2,3 ,4 ,5 ),
>c(2,2 ,2 ,2 ),
>c(3,NA,NA,6 ),
>c(3,NA,NA,3 ),
>c(2,4 ,4 ,NA),
>c(2,3 ,2 ,NA))
> distTest <- rbind(c(0,0,0,0),
> c(1,1,1,1))
> distNA <- function(x,centers){
> z <- matrix(0,nrow=nrow(x),ncol=nrow(centers))
> for(k in 1:nrow(centers)){
> z[,k]<- apply(x,1,function(x){dist(rbind(x,centers[k,]))})
> }
> z
> }
> distNA(data,distTest)
> km <- kccaFamily(dist=distNA,cent=colMeans)
> kcca(x=data,k=2,family=km)
> kcca(x=data,k=3,family=km)
I don't think this is really appropriate for r-devel, you should
either ask the package author (me), or r-help.
Anyway, colMeans will not remove the missing values by default, so you
need also a special function for centroid computation:
R> centNA <- function(x) colMeans(x, na.rm=TRUE)
R> km <- kccaFamily(dist=distNA,cent=centNA)
R> kcca(x=data,k=2,family=km)
kcca object of family ??distNA??
call:
kcca(x = data, k = 2, family = km)
cluster sizes:
1 2
5 3
Hope this helps,
Fritz
--
---
Prof. Dr. Friedrich Leisch
Institut für Statistik Tel: (+49 89) 2180 3165
Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308
Ludwigstraße 33
D-80539 München http://www.statistik.lmu.de/~leisch
---
Journal Computational Statistics --- http://www.springer.com/180
Münchner R Kurse --- http://www.statistik.lmu.de/R
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Checking package vignettes: WARNING
>>>>> On Wed, 16 Jul 2008 14:57:39 +0200,
>>>>> Arne Henningsen (AH) wrote:
> Hi Bernhard!
> On Wednesday 16 July 2008 14:16:05, you wrote:
>> I do not know if this matters, but have you used 'results = verbatim' in
>> your R code chunk? See page 13 in:
>> http://www.statistik.lmu.de/~leisch/Sweave/Sweave-manual.pdf
> Thank you for this hint. I have tried this option, but it seems to have no
> effect on the quotation marks. Hence, I still do not know whether the
> quotation marks or something else causes the warning.
verbatim is the default, so adding changes nothing if you had no
results=xxx before.
>> >German locale:
>> >
>> >'C' locale:
>> > Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
>> >
>> >German locale:
>> > Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
>> >
>> >System Information:
>> >R 2.7.1
>> >i486-pc-linux-gnu
>> >Kubuntu 8.04
>> >
In whiche locale are you running? On Debian Linux with de_AT.UTF-8
everything is fine for me.
Of course you also need something like
\usepackage[utf8]{inputenc}
to handle the special characters, but you need that anyway because
every textual output of R may contain Umlaute ...
Hth,
Fritz
--
---
Prof. Dr. Friedrich Leisch
Institut für Statistik Tel: (+49 89) 2180 3165
Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308
Ludwigstraße 33
D-80539 München http://www.statistik.lmu.de/~leisch
---
Journal Computational Statistics --- http://www.springer.com/180
Münchner R Kurse --- http://www.statistik.lmu.de/R
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] literate programming
> On Tue, 5 Aug 2008 09:38:23 -0500 (CDT), > Terry Therneau (TT) wrote: > I'm working on the next iteration of coxme. (Rather slowly during > the summer). This is the most subtle code I've done in S, both > mathematically and technically, and seems a perfect vehicle for > the "literate programming" paradym of Knuth. The Sweave project > is pointed at S output however, not source code. I would > appreciate any pointers to an noweb type client that was > R-aware. > Other suggestions are welcome as well. At the end of the day > I'd like to have a good user guide, technical reference, and solid > enough code documentation that others can begin to participate as > well. (Retirement in 10 years -- I don't expect to maintain this > forever!) Why not use the original noweb in the first place? You can even maintain Sweave files with it, the Sweave latex syntax was written for exactly that purpose ... ESS supported noweb before Sweave existed. In fact the emacs noweb mode was the main reason I chose that syntax for Sweave, and the latex syntax was added lateron because some people write whole packages using noweb and would have had a syntax conflict in their vignettes. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] literate programming
> On Wed, 6 Aug 2008 10:25:38 -0500 (CDT),
> Terry Therneau (TT) wrote:
> "ESS supported noweb before Sweave existed."
>That is the bit I didn't know. What I was rather looking for was a
noweb
> mode that knows about S formatting, and here it was available all along.
I've
> used a version of ESS for a lng time - probably should re-read the
> documentation one of these days to catch up on all the new
>features!
>"and the latex
> syntax was added lateron because some people write whole packages using
> noweb and would have had a syntax conflict in their vignettes"
> I'm not quite sure what this means.
Well, you can write your Sweave files also looking like
**
This is some latex documentation bla bla bla
And here comes a code chuck:
\begin{Scode}{echo=FALSE,fig=TRUE}
plot(rnorm(100))
\end{Scode}
and here we go again with latex
**
and Sweave will process it correctly (if the file has extension
.Rtex). As Sweave does not use noweb's magic <<>>= tags in this case,
you can use those for regular noweb processing. Of course you loose
the nice handling of code chunks by ESS in that case ...
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Google Summer of Code 2009
Hi, in approximately one months time mentoring institutions can propose projects for the Google Summer of Code 2009, see http://code.google.com/soc/ Last year the R Foundation succesfully participated with 4 projects, see http://www.r-project.org/SoC08/ for details. We want to participate again this year. Our project proposals will be managed by Manuel Eugster (email address in CC). Manuel is one of my PhD students and mentored the Roxygen project last year. This mail is mainly intended to make you aware of the program, Manuel will send a followup email with more technical details in the next days. In this phase we are looking for potential mentors who can offer interesting projects to students. I don't think that we will get much more than 4-6 projects, so don't be disappointed if you propose something and don't get selected. There are two selection steps involved: (a) The R Foundation has to compile an official "ideas list" of projects, for which students can apply. Last year we had 8 of those. After that, we (b) get a certain number of slots from Google (4 last year) and all prospective project mentors can vote on which projects actually get funding. Currently we are looking for good ideas for phase (a). I give no guarantees that all ideas will get on our official ideas list, what we pick depends on the number of submissions and topics, respectively. We want to make sure to have a broad range of themes, it is unlikely, that we will, e.g., pick 10 database projects. Also keep in mind that students have only three months time. This is not a research exercise for the students, you should have a rough idea what needs to be done. Last year we had a majority of "infrastructure projects", and only few with focus on statistical algorithms. We got a lot of applications for the latter, so don't hesitate to formulate projects in that direction. Important infrastructure may get precedence over specialized algorithms, though, because the whole community can benfit from those. But that will be a decision in phase (b), and we are not there yet. Please don't send any ideas to me right now, wait for the above mentioned email by Manuel on the technical details for idea submission. Best, Fritz -- ------- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.statistik.lmu.de/~leisch --- Journal Computational Statistics --- http://www.springer.com/180 Münchner R Kurse --- http://www.statistik.lmu.de/R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
> On Thu, 19 Feb 2009 11:47:12 +, > Robin Hankin (RH) wrote: > thanks for this clarification Uwe > Could I include the r_env_cache/ directory in the package > and then assume that the CRAN checks use > Sweave( , driver=weaver()) > in which case the process takes about 10 seconds? That makes no sense, because then there are no checks done at all: if the code in your vignette does not change, weaver will not recompute anything, hence the cached results are used. But in that case you could as well include only the PDF (or the generated .tex if you like that better) ... The whole point of checking vignettes on CRAN is that we can track errors due to changes in R or other packages. The second benefit is that users can easily play around with your code and use itr as examples ... how good an example with 10 hour runtime is depends of course on the application. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Google Summer of Code 2009
> On Thu, 19 Feb 2009 10:52:19 -0600, > Dirk Eddelbuettel (DE) wrote: > [ Cool how nobody cared about Fritz' request not to post ideas yet :) ] Well, I kind of expected that ;-) See also below. > [ I broadly share Oleg's "wouldn't it be nice to have better plot devices" > wish. But I don't think it is a three-month summer target, Yes, that's exactly what came to my mind first: As usual, please do read docs before you post ... in this case the format of SOC (I included the link in my original email, googling for "summer of code" will also take you there): a student is paid to code three months for us, the 3 months inlcude writing documentation. The student will not be an expert in R internals, and no magic wizard. The student should familiarize himself with the project before the actual coding period, but there is only so much you can do in limited time. I think you can expect a similar amount of code as in a master/diploma thesis (but NOT a dissertation). If you had waited for Manuels email you would also have learned about another VERY IMPORTANT POINT: The collection of ideas for summer of code is not like writing a list of wishes to Santa Claus (or the Christkind or whatever your local variation may be): we only need ideas which YOU ARE WILLING TO MENTOR, i.e., you write the specs for the project, communicate with students interested in the project, select the best applicant and supervise the student during the coding period. I am not sure everyone on this thread is aware about this (if all of you were I apologize). If you propose an idea, you simultaneously agree to volunteer a considerable amount of your own time. But that time can really be worth the effort (otherwise we wouldn't be doing it). > and it's not on the side of things Fritz / Manuel prefer as it is > infrastructure rather than pure statistics ... Then again, maybe > we should put that up to a wider discussion. I like > 'infrastructure' as R is a platform to me. ] I have no "preference" for pure statistics: last year we had 75% infrastructure ideas and 25% statistics. I simply want to shift the percentages to a more even ratio, because we had many application on the statistical side and I don't want to waste talent. It is also our USP in the summer of code. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
>>>>> On Thu, 19 Feb 2009 17:47:53 -0500, >>>>> Gabor Grothendieck (GG) wrote: > On Thu, Feb 19, 2009 at 5:36 PM, Friedrich Leisch > wrote: >>>>>>> On Thu, 19 Feb 2009 11:47:12 +, >>>>>>> Robin Hankin (RH) wrote: >> >> > thanks for this clarification Uwe >> > Could I include the r_env_cache/ directory in the package >> > and then assume that the CRAN checks use >> >> > Sweave( , driver=weaver()) >> >> > in which case the process takes about 10 seconds? >> >> That makes no sense, because then there are no checks done at all: if >> the code in your vignette does not change, weaver will not recompute >> anything, hence the cached results are used. But in that case you >> could as well include only the PDF (or the generated .tex if you like >> that better) ... >> > Unless this has changed recently,I've tried including a PDF but it does not > appear in library(help = myPackage) nor on the CRAN site on > http://cran.r-project.org/package=myPackage > while Sweave'd PDFs do. That was not the point of my email: If we process vignettes using the weaver package during check, then in fact no checking is done at all -> the whole purpose of vignettes is circumvented. For vignettes you can be sure that all computations have been done using the latest version of R and the package, i.e., the doc is up to date. For a PDF this is not necessarily the case. There is a good reason why we (more or less gently) try to push people writing docs as Sweave files. It is also unclear to me whether including a PDF without sources in a GPLed package isn't a violation of the GPL (I know people who very strongly think so). And source according to the GPL means "the preferred form of the work for making modifications to it." So for a PDF showing R output that would mean the text plus R code plus data ... which boils down to XXXweave anyway. But we really had this discussion several times ... perhaps somebody volunteers to write an RFC for a more general system of including manuals in R and volunteers to send patches implementing the mechanism afterwards? Note that such a system needs to be compatible with the package metadata system and work on all platforms. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Google Summer of Code 2009
>>>>> On Thu, 19 Feb 2009 20:25:35 -0600, >>>>> Dirk Eddelbuettel (DE) wrote: > On 20 February 2009 at 12:06, Friedrich Leisch wrote: > | >>>>> On Thu, 19 Feb 2009 10:52:19 -0600, > | >>>>> Dirk Eddelbuettel (DE) wrote: > | > | > [ Cool how nobody cared about Fritz' request not to post ideas yet :) ] > | > | Well, I kind of expected that ;-) > | > | See also below. > | > | > [ I broadly share Oleg's "wouldn't it be nice to have better plot devices" > | > wish. But I don't think it is a three-month summer target, > | > | Yes, that's exactly what came to my mind first: As usual, please do > | read docs before you post ... in this case the format of SOC (I > | included the link in my original email, googling for "summer of code" > | will also take you there): a student is paid to code three months for > | us, the 3 months inlcude writing documentation. The student will not > | be an expert in R internals, and no magic wizard. The student should > | familiarize himself with the project before the actual coding period, > | but there is only so much you can do in limited time. I think you can > | expect a similar amount of code as in a master/diploma thesis (but > | NOT a dissertation). > | > | If you had waited for Manuels email you would also have learned about > | another VERY IMPORTANT POINT: The collection of ideas for summer of > | code is not like writing a list of wishes to Santa Claus (or the > | Christkind or whatever your local variation may be): we only need > | ideas which YOU ARE WILLING TO MENTOR, i.e., you write the specs for > | the project, communicate with students interested in the project, > | select the best applicant and supervise the student during the coding > | period. I am not sure everyone on this thread is aware about this (if > | all of you were I apologize). If you propose an idea, you > | simultaneously agree to volunteer a considerable amount of your own > | time. But that time can really be worth the effort (otherwise we > | wouldn't be doing it). > I am not sure if you're lecturing just to me or the audience at > large; Of course to the audfiance at large, I know that you know the rules of the game. That I answered your email, in the thread was more or less chance. Sorry if I gave a wrong impression (wouldn't have possibly thought that you could feel addressed personally). My sincere apologies!!! > I would at this point also like to correct something you said in > the earlier mail where you said that may get "four to six > slots". I am doubtful about that. O verall number of GSoC slots > are _down_ as per Leslie. We have no priors on whether more or > less organisations are admitted or not. If I were a betting man, > I'd say three to four slots. OK, didn't know that number of slots is down (should probably read the docs better myself). I was assuming that the number of slots is approx the same, and hoping for more slots in the second year (because I know that all organizations get fewer in their first year). Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R tutorial
>>>>> On Sun, 22 Feb 2009 14:44:27 +0100, >>>>> Christophe Dutang (CD) wrote: > Dear all, > I have just found a 'good' tutorial R for datamining. I think it > should be on the contributed docs. > http://cran.r-project.org/other-docs.html > Here is the link > http://www.liaad.up.pt/~ltorgo/DataMiningWithR/ > What do you think? Looks intersting (although may be outdated as Doug already mentioned). In any case, we don't simply "harvest" docs off the web, we only put docs on CRAN which get sent to us by the original authors. So if you want to see it on CRAN, please contact the author (and perhaps ask for the status while doing so). Best, Fritz -- ------- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.statistik.lmu.de/~leisch --- Journal Computational Statistics --- http://www.springer.com/180 Münchner R Kurse --- http://www.statistik.lmu.de/R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Ability to suppress 'locale' from sessionInfo
> On Tue, 21 Apr 2009 21:16:59 -0500, > Kevin W (KW) wrote: > The printing of the locale information from sessionInfo is not very tidy. > Using toLatex(sessionInfo) pretty much guarantees "badness" from breaking > the margin boundary (though my version of TeX no longer reports such > errors). A random example is here: > http://cran.r-project.org/web/packages/Matrix/vignettes/Design-issues.pdf > I find the locale information unnecessary and right now I hack this with > si = sessionInfo() > si$locale = "US" > toLatex(si) > I would like to be able to do something a bit cleaner, for example > sessionInfo(locale=FALSE) > For what it's worth, I don't think that early versions of sessionInfo > printed information about the locale. It went in on 2006-05-26, so it's bben there for some time now. > Discussion welcome. I agree that it doesn't look nice in latex documents, but it is very handy in bug reports. Are there any objections if we add a locale argument to the toLatex() method and let that default to FALSE? Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Ability to suppress 'locale' from sessionInfo
> On Wed, 22 Apr 2009 12:49:05 -0700,
> Kasper Daniel Hansen (KDH) wrote:
> This is a better way, it does two things
> a) enclose the itemize environment in a flushleft environment - this
> gives us much better line breaks for the verb.
> b) does a replace of ";" with ";| \verb|" so that each "component" of
> the locale gets enclosed in its own \verb command, which allows latex
> to produce line breaks (since I am using gsub, I do gsub(";", ";| \\\
> \verb", object$locale))
> Below is a proposed utils:::toLatex.sessionInfo
Thanks, I have integrated it into the devel branch, and also modified
the print method to split the locale information:
R> sessionInfo()
R version 2.10.0 Under development (unstable) (2009-04-23 r48380)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
The default for the new locale argument is TRUE.
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Closed-source non-free ParallelR ?
>>>>> On Thu, 23 Apr 2009 00:36:48 +0100, >>>>> Matthew Dowle (MD) wrote: [...] > Could someone from the R Foundation or the FSF step in and clarify the > situation please ? Just a short clarification (by no means intended to stop the thread): as you can imagine we are discussing the matter internally in R Core and the Foundation, but there are different views and we want to consolidate before we make a public statement. If all of us were of the same opinion we would already have made one. Unfortunately New Zealand, Europe and the US are in quite different time zones, hence discussions by email take some time. Best regards, Fritz Leisch -- ------- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.statistik.lmu.de/~leisch --- Journal Computational Statistics --- http://www.springer.com/180 Münchner R Kurse --- http://www.statistik.lmu.de/R __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] link to latest package announcements
> On Wed, 29 Apr 2009 10:24:53 -0400, > Max Kuhn (MK) wrote: > I wasn't sure where to send this... > On the "What's New" section of the homepage, the "Latest" package link > points towards >https://stat.ethz.ch/pipermail/r-packages/2008/date.html#end > It should probably point towards 2009. Thanks for spotting this, submitted bugfix to SVN (will automatically go live in an hour or so). Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Citation of R packages
>>>>> On Fri, 10 Feb 2006 21:01:44 +1100,
>>>>> John Maindonald (JM) wrote:
[...]
> Where there is a published paper or a book (such as MASS), or a
> manual for which a url can be given, my decision was to include
> that in the main list of references, but not to include references
> there that were references to the package itself, which as you
> suggest below can be a reference to the concatenated help pages.
The CITATION file of a package may contain as many entries as the
author wants, including both a reference to the help pages and to the
book (or whatever).
> It seemed anyway useful to have a separate list of packages. For
> consistency, these were always references to the package, with a
> cross-reference to any relevant document in the references to papers.
>>> (2) Maybe the author field should be more nuanced, or
>>> maybe ...
>>
>> author fields of bibtex entries have a strict format (names separated
>> by "and"), what do you mean by "more nuanced"?
> Those named in the list of authors may be any combination of: the
> authors
> of an R package, the authors of an original S version, the person or
> persons
> responsible for an R port, the authors of the Fortran code, compiler
> (s), and
> contributors of ideas.
> For John Fox's car, citation() gives the following:
> author = {John Fox. I am grateful to Douglas Bates and David
> Firth and Michael Friendly and Gregor Gorjanc and Georges Monette and
> Henric Nilsson and Brian Ripley and Sanford Weisberg and and Achim
> Zeleis for various suggestions and contributions.},
> For Rcmdr:
> author = {John Fox and with contributions from Michael Ash and
> Philippe Grosjean and Martin Maechler and Dan Putler and and Peter
> Wolf.},
> For car, maybe John Fox should be identified as author. For Rcmdr,
> maybe the other persons that are named should be added?
> For leaps:
> author = {Thomas Lumley using Fortran code by Alan Miller},
> It seems reasonable to cite Lumley and Miller as authors. Should
> there be a note that identifies Miller as the contributor of the
> Fortran code?
> Should the name(s) of porters (usually from S) be included as author
> (s)? Or should their contribution be acknowledged in the note field?
> Or ...
> Possibilities are to cite all those individuals as author, or to cite
> John Fox only,
> with any combination of no additional information in the note field,
> or using the
> note field to explain who did what. The citation() function leaves
> it unclear who
> are to be acknowledged as authors, and in fact
Umm, the problem there is not the citation() function, but that the
authors of all those packages obviously have not included a CITATION
file in their package which overrides the default (extracted from the
DESCRIPTION file).
E.g., package flexclust has DESCRIPTION
Package: flexclust
Version: 0.8-1
Date: 2006-01-11
Author: Friedrich Leisch, parts based on code by Evgenia Dimitriadou
but
R> citation("flexclust")
To cite package flexclust in publications use:
Friedrich Leisch. A Toolbox for K-Centroids Cluster Analysis.
Computational Statistics and Data Analysis, 2006. Accepted for
publication.
A BibTeX entry for LaTeX users is
@Article{,
author = {Friedrich Leisch},
title = {A Toolbox for K-Centroids Cluster Analysis},
journal = {Computational Statistics and Data Analysis},
year = {2006},
note = {Accepted for publication},
}
because the CITATION file overrides the DESCRIPTION file. Writing a
CITATION file is of course also intended for those cases where a
proper reference cannot be auto-generated from the DESCRIPTION file.
>>> (3) In compiling a list of packages, name order seems
>>> preferable, and one wants the title first (achieved by
>>> relocating the format.title field in the manual FUNCTION
>>> in the .bst file
>>> (4) manual seems not an ideal name for the class, if
>>> there is no manual.
>>
>> A package always has a "reference manual", the concatenated help pages
>> certainly qualify as such and can be downloaded in PDF format from
>> CRAN. The ISBN rules even allow to assign an ISBN number to the online
>> help of a software package which also can serve as the ISBN number of
>> the *software itself* (which we did for base R).
> I'd prefer some consistency in the way that R packages are referenced.
> Thus, if reference for one package is to the concatenated help pages,
> do it that way for all of them.
But we recommend that package authors
Re: [Rd] Bug in Sweave? -- scoping problem? (PR#8615)
I will add it to the FAQ. fritz > On Sun, 19 Feb 2006 08:42:09 -0500, > Duncan Murdoch (DM) wrote: [...] > Code in chunks that produce pictures is executed several times. > First, to produce the output in the text. And then once more > for *each* format in which the figure has to be produced. I.e., > if you want a PDF and a PostScript version of the figure, the > code is executed a total of three times. > Thanks, that's what caught me. Is that a quote from the discussion, or > from the docs somewhere? It makes sense in hindsight, but it's not > obvious ahead of time, so it should be stated fairly prominently in the > docs. > Duncan Murdoch >> >> All instances of this feature reported so far involved commands that >> produced random numbers and the poster was surprised that the output >> in the text and the figures differed (and that the two figures were >> different). >> >> In your case the first execution of the code assigns the names to >> partytotal, sorts partytotal and produces the data. On the next >> execution, when the picture is produced, partytotal is already sorted >> but you reassign the names. Then the partytotal is sorted again and >> the plot is produced. But that re-assigning of names lead to the >> disconnect between values and names. >> >> Hope this helps. >> >> Cheers, >> >> Berwin >> >> == Full address >> Berwin A Turlach Tel.: +61 (8) 6488 3338 (secr) >> School of Mathematics and Statistics+61 (8) 6488 3383 (self) >> The University of Western Australia FAX : +61 (8) 6488 1028 >> 35 Stirling Highway >> Crawley WA 6009e-mail: [EMAIL PROTECTED] >> Australiahttp://www.maths.uwa.edu.au/~berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist - Give R a name that shows up in search engines ...
> On Wed, 08 Mar 2006 14:55:51 +, > Hin-Tak Leung (HL) wrote: > roger bos wrote: >> Indeed, when I was writing code in Java or VBA and I needed code, say to >> buble sort or invert a CDF, I could find many examples on the web since >> the user base was so large. R has something better: CRAN. It was >> really smart to make a central repository where useRs can share code. >> No other language that I can think of really has an equivalent. All I >> have to do it search CRAN and I can find 99% of what out there (I'm >> making a guess on the actual number here). > > Hang on there - "No other language that I can think of really has > an equivalent." - have you heard of CPAN, and CTAN? CRAN > was modelled *after* CPAN, which in turn was modelled after CTAN... > Either of them is far bigger in size, far older in history, and far > more well-established. > In fact, I am sorry to say, the search engine of either CPAN or CTAN > are better than CRAN's. (this last sentence is subjective, of course). > Obviously not a Perl nor TeX user then. > (probably not a good idea to express this on r-devel, nevermind) No problem at all ... I take it you volunteer to design, setup, host, and maintain a better system? Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweaving in png
Yes, I have that on mmy 2do list for quite some time now. Could you
send me your patches to the code?
Fritz
> On Sun, 26 Mar 2006 19:58:40 -0500,
> Roger Peng (RP) wrote:
> For what it's worth, I would find such a adaptation useful.
> -roger
> Thibaut Jombart wrote:
>> Hello list,
>>
>> despite I already posted a mail on this topic on R help, I guess this
place may be more appropriate.
>> I'll make it shorter this time. Sorry for posting twice.
>>
>> I found that using pixmap pictures in a Sweave document was sometimes
almost impossible, due to the huge size of the pdf pictures produced.
>>
>> The first solution I found was to save pictures in png, when too heavy in
pdf. Here is an example:
>>
>> ### in a .rnw document ###
>>
>> % here is an invisible chunck to create a picture
>> <>=
>> png(filename='figs/myPic.png')
>> @
>>
>> % next, R code to generate picture
>> <>=
>> ...[code to produce the figure]
>> @
>>
>> % then, close the device. Hidden, again
>> <>=
>> dev.off()
>> @
>>
>> % and then, include it as a picture
>> \includegraphics{figs/myPic.png}
>>
>> ### end of the example ###
>>
>> I
>> This is quite long, and I would have prefered to need simply:
>>
>> <>
>> ...[code to produce the figure]
>> @
>>
>> So I tried to adapte the Sweave driver 'RweaveLatex' in order to do so. It
worked.
>>
>> The not-so-new driver is only a slight modification of RweaveLatex, and
can
>> generate ps, pdf or png figures; it was tested on Ubuntu64, Debian,
>> several Windows systems and macOS X partforms with no detected problem.
>>
>> Does someone find this useful, and/or were there better solutions I missed?
>>
>> Regards,
>>
>> Thibaut Jombart .
>>
> --
> Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
> __
> 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] compress defaults for save() and save.image()
> On Thu, 30 Mar 2006 18:23:11 +0100 (BST), > Prof Brian Ripley (PBR) wrote: > I have changed the default in save() to compress = !ascii. This seems > quite safe, as almost always save() is called explicitly and people will > appreciate that it might take a little time to save large objects (and > depending on your system, compression could even be faster). Very good idea. > Should we also change the default in save.image()? That is almost always > used implicitly, via q(), a menu There are arguments that it is a > more serious change so should not be done at the end of the release cycle, > and also that large .RData files are something people would want to avoid. > BTW, the defaults can be changed via options() (see ?save): has anyone > ever found that useful? Yes, I and many people I know have options(save.defaults=list(compress=TRUE)) in our settings, and I'd like to keep the option version such that I am independent from whatever the function defaults are. > Liaw, Andy wrote: > - I always use save(..., compress=TRUE), without exception. > - The only time I'd use save.image() is when I need to break a remote > connection on short notice. > - I have not used options() to set the default simply because I have not > figured out how exactly to do it. From what I remember, the doc simply says > it can be done, but does not explicitly say how. Umm, there is an explicit example in help(save), I have added a pointer from the main text of the help page. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending www.r-project.org features with a Wiki (PR#8744)
[removed from r-bugs] > On Mon, 3 Apr 2006 17:36:35 +0200 (CEST), > ripley (r) wrote: > Try http://wiki.r-project.org (which you might have guessed or Googled: > it came up as the first item for me). > You might want to report to the webmaster of www.r-project.org where you > looked for a link to this and failed to find one. (Both the webmaster > and the host machine have moved recently (or the machine is about to), so > various planned changes are delayed by the moves.) Actually Martin had written in his email requesting the DNS entry for the wiki that the machine hosting the wike "will be available soon" and I was waiting for an email that this had happened. Martin or Philippe: Is everything up and running or are you still in a "testing phase"? Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug#361968: Wrong name in manpage
> On Tue, 11 Apr 2006 20:56:27 -0400,
> Duncan Murdoch (DM) wrote:
> On 4/11/2006 7:45 PM, Dirk Eddelbuettel wrote:
>> R-devel'ers,
>>
>> On 11 April 2006 at 10:24, Dirk Eddelbuettel wrote:
>> |
>> | Kanru,
>> |
>> | Thanks for the bugreport.
>> |
>> | On 11 April 2006 at 22:03, Kanru Chen wrote:
>> | | Package: r-base-core
>> | | Version: 2.2.1.svn37668-1
>> | | Severity: minor
>> | |
>> | | In manpage of /usr/bin/R, the first, fourth and last line shows
`VERSION'
>> | | instead of `R'.
>>
>> I haven't seen any follow-up yet -- here is what it looks like (cut and
>> pasted from Emacs man page viewer) and note the 'Version' in place of R:
>>
>> VERSION(1)FSF
VERSION(1)
>>
>> NAME
>> Version - a language for data analysis and graphics
>>
>> SYNOPSIS
>> R [options] [< infile] [> outfile]
>> R CMD command [arguments]
>>
>> DESCRIPTION
>> Start R, a system for statistical computation and graphics, with the
>> specified options, or invoke an R tool via the 'R CMD' interface.
>> [...]
>>
>>
>> | | I believe it is a typo.
>> |
>> | More likely something is wrong with how R.1 is autogenerated using
help2man.
>> |
>> | Incidentally, that `R --version' now starts its ouput with 'Version'
rather
>> | than R had bit us in the RPy builds where the version number was
regexp'ed
>> | out of the result, and was still expecting the line to start with R just
like
>> | help2man seems to expect the program name first.
>>
>> It seems to stem from src/main/version.c:
>>
>> void attribute_hidden PrintVersionString(char *s)
>> {
>> if(strcmp(R_SVN_REVISION, "unknown")==0)
>> {
>> sprintf(s, "Version %s.%s %s (%s-%s-%s)",
>> R_MAJOR, R_MINOR, R_STATUS, R_YEAR, R_MONTH, R_DAY);
>> }
>> else{
>> if(strlen(R_STATUS)==0){
>> sprintf(s, "Version %s.%s (%s-%s-%s)",
>> R_MAJOR, R_MINOR, R_YEAR, R_MONTH, R_DAY);
>> }
>> else{
>> sprintf(s, "Version %s.%s %s (%s-%s-%s r%s)",
>> R_MAJOR, R_MINOR, R_STATUS, R_YEAR, R_MONTH, R_DAY,
>> R_SVN_REVISION);
>> }
>> }
>> }
>>
>> Would replacing 'Version ...' with 'R (Version ...)' be an acceptable
>> alternative ?
> I think the problem is that PrintVersion (a few lines up from there)
> used to put the R in front; PrintVersionString doesn't include the R.
> PrintVersionString is called from other places where the R would not be
> appropriate, but PrintVersion is only called when acting on `R
> --version' or synonyms.
> Fritz, I think this was your change in r36923 a few months ago. Do you
> have time to deal with it?
Yes, will do later today.
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug#361968: Wrong name in manpage
I've committed a fix for 2.3 affecting only "R --version" (don't want to
play with real R output during feature freeze), and a cleaner solution
for 2.4 which gets the startup message and --version even more in
sync.
Passes all checks for me, and the man page looks OK again. Thanks for
spotting the bug.
Best,
Fritz
>>>>> On Wed, 12 Apr 2006 13:53:08 +0200,
>>>>> friedrich leisch (fl) wrote:
>>>>> On Tue, 11 Apr 2006 20:56:27 -0400,
>>>>> Duncan Murdoch (DM) wrote:
>> On 4/11/2006 7:45 PM, Dirk Eddelbuettel wrote:
>>> R-devel'ers,
>>>
>>> On 11 April 2006 at 10:24, Dirk Eddelbuettel wrote:
>>> |
>>> | Kanru,
>>> |
>>> | Thanks for the bugreport.
>>> |
>>> | On 11 April 2006 at 22:03, Kanru Chen wrote:
>>> | | Package: r-base-core
>>> | | Version: 2.2.1.svn37668-1
>>> | | Severity: minor
>>> | |
>>> | | In manpage of /usr/bin/R, the first, fourth and last line shows
`VERSION'
>>> | | instead of `R'.
>>>
>>> I haven't seen any follow-up yet -- here is what it looks like (cut and
>>> pasted from Emacs man page viewer) and note the 'Version' in place of R:
>>>
>>> VERSION(1)FSF
VERSION(1)
>>>
>>> NAME
>>> Version - a language for data analysis and graphics
>>>
>>> SYNOPSIS
>>> R [options] [< infile] [> outfile]
>>> R CMD command [arguments]
>>>
>>> DESCRIPTION
>>> Start R, a system for statistical computation and graphics, with the
>>> specified options, or invoke an R tool via the 'R CMD' interface.
>>> [...]
>>>
>>>
>>> | | I believe it is a typo.
>>> |
>>> | More likely something is wrong with how R.1 is autogenerated using
help2man.
>>> |
>>> | Incidentally, that `R --version' now starts its ouput with 'Version'
rather
>>> | than R had bit us in the RPy builds where the version number was
regexp'ed
>>> | out of the result, and was still expecting the line to start with R
just like
>>> | help2man seems to expect the program name first.
>>>
>>> It seems to stem from src/main/version.c:
>>>
>>> void attribute_hidden PrintVersionString(char *s)
>>> {
>>> if(strcmp(R_SVN_REVISION, "unknown")==0)
>>> {
>>> sprintf(s, "Version %s.%s %s (%s-%s-%s)",
>>> R_MAJOR, R_MINOR, R_STATUS, R_YEAR, R_MONTH, R_DAY);
>>> }
>>> else{
>>> if(strlen(R_STATUS)==0){
>>> sprintf(s, "Version %s.%s (%s-%s-%s)",
>>> R_MAJOR, R_MINOR, R_YEAR, R_MONTH, R_DAY);
>>> }
>>> else{
>>> sprintf(s, "Version %s.%s %s (%s-%s-%s r%s)",
>>> R_MAJOR, R_MINOR, R_STATUS, R_YEAR, R_MONTH, R_DAY,
>>> R_SVN_REVISION);
>>> }
>>> }
>>> }
>>>
>>> Would replacing 'Version ...' with 'R (Version ...)' be an acceptable
>>> alternative ?
>> I think the problem is that PrintVersion (a few lines up from there)
>> used to put the R in front; PrintVersionString doesn't include the R.
>> PrintVersionString is called from other places where the R would not be
>> appropriate, but PrintVersion is only called when acting on `R
>> --version' or synonyms.
>> Fritz, I think this was your change in r36923 a few months ago. Do you
>> have time to deal with it?
> Yes, will do later today.
> Best,
> Fritz
> __
> 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] Suggesting changes to HELP files?
> On 5/21/06, Spencer Graves <[EMAIL PROTECTED]> wrote: >> Is there a procedure for suggesting changes to HELP files of the core >> R distribution? If yes, what is it? If it would be considered a >> friendly gesture, I could find the relevant *.Rd file and submit a >> suggested modification to it someplace. Alternatively, I could just >> send suggestions someplace if they would receive appropriate >> consideration. >> As Duncan Murdoch already pointed out the easiest way of finding out who in R core is responsible for which part of R is looking at the subversion logs to see who has been working on a particular file, for most Sweave & Vignette-related parts that would be me. >> >> Second, I think the description of 'vignette' could be enhanced to >> include some version of my 'p.s.' to >> 'http://finzi.psych.upenn.edu/R/Rhelp02a/archive/73494.html' and other >> similar posts. In particular, I see that the 'edit' method is described >> there, but I didn't understand what it said until I already knew how to >> use it. Also, 'edit' doesn't work for me under ESS / Emacs. For that, >> I use Stangle (as Sundar Dorai-Raj taught me). Done in r-devel, pls have a look. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Vignettes on CRAN
> On Mon, 22 May 2006 21:42:34 -0700, > Seth Falcon (SF) wrote: > "Gabor Grothendieck" <[EMAIL PROTECTED]> writes: >> This would certainly be nice. >> >> Note that the BioConductor package vignettes are online: >> http://www.bioconductor.org/docs/vignettes.html >> but there is nothing comparable for CRAN. > That page is actually out of date (we'll be updating it real soon > now). However, we are producing links to package vingnettes in the > automatically generated package summary pages. For example, take a > look at the summary page for the Biobase package: > http://bioconductor.org/packages/1.8/bioc/html/Biobase.html > This was fairly easy to setup. I would be happy to share the code, > etc. That looks excellent, I would be happy to use somethink like that for CRAN. But as Kurt already said: looks more like a summer project (currently I am swamped with teaching). .f __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bitmap device available for R CMD check?
>>>>> On Wed, 31 May 2006 10:57:54 -0400, >>>>> Kuhn, Max (KM) wrote: > Hi, > I have a package that I'd like to submit to CRAN that does Sweave-like > processing on Open Document format files from Open Office. Sounds very interesting! > If I remember correctly, there is a machine that automatically R CMD > checks CRAN packages. I have two questions about how that system is set > up: > 1. Is the bitmap device available? The example produces a file using > this device and I'd like it to pass R CMD check on your system (as it > does on my machines). Yes, at leats for the main check machine (running Debian Linux). I cannot speak for the Windows and MacOS checks, but I don't see why ghostscript shouldn't be available there, too. > 2. Are there any restrictions on the Latex packages called in the > vignette? This is not a big deal, but it would be good to know how much > flexibility I have in producing that document. We do not run latex on the vignette (this *is* documented), only the R code is checked. The reason is exactly your question: Latex is to heterogenous to assume we have all packages the author of a vignette has, and we do not want to limit the typesetting. HTH, Fritz -- ------- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.stat.uni-muenchen.de/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bitmap device available for R CMD check?
>>>>> On Wed, 31 May 2006 11:11:08 -0400, >>>>> Gabor Grothendieck (GG) wrote: > Others may have better ideas but if you have a problem getting > your vignette to pass R CMD check then you could process it > yourself using Sweave to create a .tex file and then have a > mypkg.Rnw file that just contains the SweaveOpt, %Vignette > statements and an \input statement to input the .tex file that you > generated yourself. That way you can generate it in a known > environment. Please do not give advice on the R lists on how to cheat the R check process (unless there is really good reason for it), it's not like we implement the tests just for the fun of bothering developers. Simply compare installing and automatically updating a couple of hundred R packages on all major computing platforms to installing the same number (OK, there aren't nearly as many) S toolboxes from Statlib in Splus and you may get an idea why enforced standards may not be so bad after all ... We have already discussed several times on this list that a) "vignette" is a reserved name for documents where - the user can both read a version in PDF format and get a handle on the code in electronic form - R CMD check can test all R code contained in the document, such that the user can rely on the code being up to date b) we currently have only infrastructure for doing a) for documents in Sweave format c) you can put documents in other formats into inst/doc, but these may not call themselves vignettes. d) I have already offered to provide a better indexing infrastructure for documents from c) for R 2.4, but that is a summer project. Most of the above is explained in "Writing R Extensions". Best, Fritz -- ------- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.stat.uni-muenchen.de/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish/suggestion: add output of citation() to package "manuals" (PR#9009)
> On Tue, 20 Jun 2006 12:22:42 +0200 (CEST), > gregor gorjanc (gg) wrote: > Dear R core, > influenced by recent panel discussion in Vienna I think that it would be > nice to add package specific output of citation() function to package > reference manuals. I think that apropriate place would be just after > fields from DESCRIPTION file. This will be OK for CRAN, but not for > locally installed packages as there is not reference manual there (at > least on my linux box) - why is this the case? Perhaps output of > citation() could be added to package specific help page i.e. to > mypackage.package.Rd file. Yes, very good idea, I have put it onto my 2do list for 2.4. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish/suggestion: add output of citation() to package "manuals" (PR#9010)
> On Tue, 20 Jun 2006 12:22:42 +0200 (CEST), > gregor gorjanc (gg) wrote: > Dear R core, > influenced by recent panel discussion in Vienna I think that it would be > nice to add package specific output of citation() function to package > reference manuals. I think that apropriate place would be just after > fields from DESCRIPTION file. This will be OK for CRAN, but not for > locally installed packages as there is not reference manual there (at > least on my linux box) - why is this the case? Perhaps output of > citation() could be added to package specific help page i.e. to > mypackage.package.Rd file. Yes, very good idea, I have put it onto my 2do list for 2.4. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette("introduction") causes "Error in sprintf(" (PR#9069)
> On Sun, 09 Jul 2006 19:21:25 +0100,
> Chris Evans (CE) wrote:
> Gabor Grothendieck sent the following at 09/07/2006 19:02:
>> Same for me. Looking through the output of vignette
>> I noticed that both the ggplot and reshape packages have
>> a vignette called "introduction" in my case and either of
>> the following brings up the associated vignette (as opposed
>> to the error message):
>>
>> vignette("introduction", "ggplot")
>> vignette("introduction", "reshape")
> Aha, works for me too. Sorry, I probably should have been able to work
> that out myself.
> So: not so much a bug, more a wish as it might be good if the vignette
> code checked for multiple vignettes with the same name and returned a
> choice or a message warning you that there are multiples.
A simple traceback shows that the bug was actually in code trying
to do exactly what you suggest ;-)
R> vignette("introduction")
Error in sprintf(gettext(fmt, domain = domain), ...) :
use format %s for character objects
R> traceback()
4: sprintf(gettext(fmt, domain = domain), ...)
3: gettextf("vignette '%d' found more than once,\nusing the one found in '%s'",
topic, dirname(pdf[idx]))
2: warning(gettextf("vignette '%d' found more than once,\nusing the one found
in '%s'",
topic, dirname(pdf[idx])), call. = FALSE, domain = NA)
1: vignette("introduction")
Fixed now in both r-patched and r-devel.
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave processes comments incorrectly (PR#9073)
> On Tue, 11 Jul 2006 16:46:02 +0200 (CEST), > krc (k) wrote: > Full_Name: Kevin R. Coombes > Version: 2.1.0 ^ Please note that this version of R is very outdated, please only report bugs which are verified for the most recent version of R (in this case it was still there, though). > OS: Windows XP > Submission from: (NULL) (143.111.22.24) > I have a source file "devel.Rnw" that uses the LaTeX foils class and ppower4 to > produce a PDF presentation file. It starts with a commented note to myself as > follows: [...] Thanks a lot for the bug report, fixed in r-patched and r-devel. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Bioc-devel] Sweave windows style path (was Re: texmf error on 7 packages on devel winXP build nodes)
> On Sun, 27 Aug 2006 07:45:00 -0700,
> Martin Morgan (MM) wrote:
> [A build system misconfiguration at Bioconductor lead to a discussion
> about whether \usepackage{Sweave} should be included in .Rnw
> documents. Leaving this line out causes a problem on Windows, as
> indicated below.]
> I think the problem is '~', which should, according to Donald
> Arseneau's comment in this thread
>
http://groups.google.com/group/comp.text.tex/browse_thread/thread/640e89078d0697c4/5b6f9fc6b0da21bf?lnk=gst&q=windows+file+path&rnum=4#5b6f9fc6b0da21bf
> be \string~. If this is the correct change, perhaps an upstream fix
> could be introduced in src/library/util/R/Sweave.R.
Sorry to join in late, I am currently at a conference with limited
access to the Internet. I am not su sure how easy it is to make the
conversion, i.e. if it is save to unconditionally change all tildes in
the path as suggested above. Does anybody have any experience wether
that is save on all platforms and TeX installations?
Personally I think it would make a lot of sense if the Bioconductor
check machines could include a version of RHOME/share/texmf in their
TeX input path ... that would also allow to use Rd.sty etc.
Otherwise most of what has been said in this thread is true: The full
path is inserted into the document by Sweave such that you donnot have
to copy something from RHOME to your tex installation every time you
install a new version of R.
On Unix it is easy: Put /usr/local/lib/R/share/texmf (or wherever you
typically install your default R) into your tex path and you are
done. On windows the normal R installation path contains the version
number, so this will fail. Hence I did the path thing in R as a
convenience for authors (and to make sure that R version and
Sweave.sty are consistent, but the .sty is pretty stable anyway).
Maybe the installer could/should create
c:\programme\R\R-latest
as a link to the newest installed version?
Just a thought.
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
> On 8/29/2006 4:13 PM, Paul Gilbert wrote: >> >> Duncan Murdoch wrote: [...] > > This doesn't address the problem of someone who hasn't got the package > installed yet, though perhaps CRAN could put a version of that man page > (or all of them) online for browsing. Unfortunately this hasn't > happened yet, but maybe we'll get to it before 2.5.0. The help pages are available on CRAN in PDF format, if there are strong preferences to also get the HTML version online that should not be a major problem. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
> Duncan Murdoch <[EMAIL PROTECTED]> writes: >> I think we need an option to R CMD check rather than a new field in the >> DESCRIPTION. Currently a package could be mentioned for any of these >> reasons: >> >> 1. To make functions, examples or vignettes work >> 2. To allow optional functionality in functions, examples or vignettes. >> 3. Because it contains complementary functions. >> >> I don't think we really need to worry about 3: it should be contained >> in 1 or 2, if reasonably complete examples are given. >> >> Case 1 is handled by Depends. > > I think there is an important distinction between a dependency needed > for the package to function and a dependency needed to demonstrate > said functionality via an example or vignette. The former is what > Depends is about, the latter is something else (Suggests). Sorry to join in late, I am at the Compstat conference and have limited email access. What Seth describes in the above paragraph is exactly what I had in mind when splitting the single Depends field we had into Depends and Suggests: Depends are a necessity to run the package, Suggests is nice to have but not necessary. If you know how to use a package you may the decide not to install a package that is only suggested, but * may not be interested to execute the examples, * know that you never need the extra functionality * ... so it should not be auto-installed unless you ask for it (the default could also be the other way round, the point is that it should be possible to have package foo but not the packages it only suggests). On CRAN we check with all suggestions to test all bits and pieces, having an option in R CMD check to test only with suggests may be nice, if there is use for it. Ad the wording in the manual: obviously that is not optimal (otherwise no need for parts of this email thread), perhaps somebody else than the original author (=me) could try to improve it for 2.4 after this clarifications? Otherwise I will give it a shot next week after I return from Rome. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
> On 8/30/2006 3:21 AM, [EMAIL PROTECTED] wrote: >>> On 8/29/2006 4:13 PM, Paul Gilbert wrote: Duncan Murdoch wrote: >> >> [...] >> >>> This doesn't address the problem of someone who hasn't got the package >>> installed yet, though perhaps CRAN could put a version of that man page >>> (or all of them) online for browsing. Unfortunately this hasn't >>> happened yet, but maybe we'll get to it before 2.5.0. >> >> The help pages are available on CRAN in PDF format, if there are strong >> preferences to also get the HTML version online that should not be a >> major >> problem. > > Just to clarify: "this hasn't happened yet" was meant to apply to the > earlier part of my message, the changes necessary to make the package > man page easier to maintain. Sure, that is how I read it (sorry for not deleting your last sentence in my reply). The question remains wether we should put HTML pages of all package help pages on CRAN? Kurt builds them anyway when checking the packages, so it is mostly a matter of copying them into the HTTP tree and some linking. Why we did not do it so far is that it really increases the size of mirrors a lot, as those files would not be compressed (nd there are heaps of them). Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
>>>>>> "FrL" == friedrich leisch <[EMAIL PROTECTED]>
>>>>>> on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:
>
> >> Duncan Murdoch <[EMAIL PROTECTED]> writes:
> >>> I think we need an option to R CMD check rather than a new field
> in the
> >>> DESCRIPTION. Currently a package could be mentioned for any of
> these
> >>> reasons:
> >>>
> >>> 1. To make functions, examples or vignettes work
> >>> 2. To allow optional functionality in functions, examples or
> vignettes.
> >>> 3. Because it contains complementary functions.
> >>>
> >>> I don't think we really need to worry about 3: it should be
> contained
> >>> in 1 or 2, if reasonably complete examples are given.
> >>>
> >>> Case 1 is handled by Depends.
> >>
> >> I think there is an important distinction between a dependency
> needed
> >> for the package to function and a dependency needed to demonstrate
> >> said functionality via an example or vignette. The former is what
> >> Depends is about, the latter is something else (Suggests).
>
> FrL> Sorry to join in late, I am at the Compstat conference and have
> limited
> FrL> email access. What Seth describes in the above paragraph is
> exactly what I
> FrL> had in mind when splitting the single Depends field we had into
> Depends
> FrL> and Suggests: Depends are a necessity to run the package,
> Suggests is nice
> FrL> to have but not necessary. If you know how to use a package you
> may the
> FrL> decide not to install a package that is only suggested, but
>
> FrL> * may not be interested to execute the examples,
> FrL> * know that you never need the extra functionality
> FrL> * ...
>
> FrL> so it should not be auto-installed unless you ask for
> FrL> it (the default could also be the other way round, the
> FrL> point is that it should be possible to have package foo
> FrL> but not the packages it only suggests). On CRAN we
> FrL> check with all suggestions to test all bits and pieces,
> FrL> having an option in R CMD check to test only with
> FrL> suggests may be nice, if there is use for it.
>
> Yes.
> However, I see two (related) problems with the current 'Suggests'
> and that's why I opened this thread proposing to have a
> (what I now would want to simply call) 'canUse' :
>
> 1) For 'R CMD check' (and hence CRAN checking),
>Packages in 'Suggests' must be require()able, and
>hence all testing only happens *with* the suggested packages
>being there, and not without.
>
> 2) "Suggests" suggests to the human reader of DESCRIPTION that
>the package authors suggest to also install the packages listed
>there.
>Now there are cases, I (as package author) want to show some
>stuff, or even provide compatibility functionality for some
>packages that are related to mine, but which I really do not
> ``suggest''
>to also be installed, e.g., because the other packages do
>similar stuff as mine, but I believe my package to be
>superior. In such a case, I may, e.g., want to provide
>functions for porting the other package classes to my package's.
>
> Duncan Murdoch has proposed to take care of "1)" by
> still only use 'Suggests' but adding another option to 'R CMD
> check', let's say --no-suggests which would run all the
> checks without having the suggested packages available
> --- something not quite easy to implement, BTW:
> Imagine the typical windows users who (AFAICS) always only use
> one library into which they install all packages.
> How do you want the
> if( require() ) {
>...
> }
> clause *not* to be triggered in such a case ?
> I do agree quite a bit that such a '--no-suggests' option would
> be very useful for 'R CMD check' -- in addition to my proposal.
>
> Further, I think "2)" above is not taken care of anyway.
> After all the interesting statements and alternative proposals,
> I'm still proposing to introduce a 'canUse' field for DESCRIPTION
> which
> a) has a "human-readable intent" of being weaker than 'Suggests'
> b) will not require its packages to be available for R CMD check
> c) conveys extra information about the package's context, to humans, and
> d) will potentially
Re: [Rd] R-Project logo in SVG format
> Hi, > > I'm looking for a version of the R-Project logo in SVG format. I've found > the bitmapped versions, > http://developer.r-project.org/Logo/ > > but would prefer a scalable version as it usually looks better when > printed. > > Where may I find one? After you created one and submitted it to us probably at the same place as the bitmaps. In the meantime it will have to suffice that you use all we have, and that are the bitmaps (the logo was done by a volunteer who chose to use a bitmapped graphics program). It is not like we keep the good stuff back on purpose ... Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Project logo in SVG format
> On Thu, 31 Aug 2006 16:55:38 +0100, > Barry Rowlingson (BR) wrote: > [EMAIL PROTECTED] wrote: >> After you created one and submitted it to us probably at the same place as >> the bitmaps. In the meantime it will have to suffice that you use all we >> have, and that are the bitmaps (the logo was done by a volunteer who chose >> to use a bitmapped graphics program). It is not like we keep the good >> stuff back on purpose ... > It does look like it would be near-impossible to parameterise the logo > efficiently into a vector format - all that shading and 3-d effect > stuff. The largest PNG file there is 1450x1100 pixels which at 300 dpi > gives you a 4-inch logo. Although looking at it full-size on my monitor > reveals some artifacts in the 3-d shading... > Do any other materials exist for making the logo? A description of the > fonts used, a 3-d model R and O-shape, a layered PSD or XCF file, or a > Gimp/Photoshop macro set for getting that effect? I dont believe this > was painted pixel-by-pixel... No, certainly not. But you would have to ask Stefano Iacus about details, he contributed the files. IIRC a relative of Stefano did the actual work. > When was the last time the mailing list had a 'need a new logo' thread? ;-) .f __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Project logo in SVG format
> On Fri, 1 Sep 2006 08:56:03 -0700, > Don MacQueen (DM) wrote: > I have a file named Rlogo-5.svg, created by > downloading Rlogo-5.png, opening it with Adobe > Illustrator, Saving as SVG. > I didn't tinker with any of Illustrator's options > with regard to how, exactly, to save it, since I > pretty much don't know what they mean. Whether it > is of any use to anyone, or whether it is truly > scalable, I have no idea. All I know is that > Illustrator claims it is an SVG file. > Took about 2 minutes, all together (writing this email took longer). > If any R Core member (or anyone else, for that > matter), wants a copy, please let me know. I > don't want to burden lots of people with a file > they probably don't want. I guess that Illustrator simply has embedded the bitmap into the SVG file, such that scaling properties are the same. I know how to "convert" the PNG to EPS or PDF (and it takes even less than two minutes), but that again simply embeds the bitmap, so nothing gained. To be sure you can send me the SVG, I'll have a look. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Citation through time
> On Tue, 12 Sep 2006 07:53:52 +0200,
> Gregor Gorjanc (GG) wrote:
> Hello!
> I keep my local bib file and up to now I had entry
> @Manual{R:2003,
> title = {R: A Language and Environment for Statistical Computing},
> author = {{R Development Core Team}},
> organization = {R Foundation for Statistical Computing},
> address = {Vienna, Austria},
> year = {2005},
> note = {{ISBN} 3-900051-00-3},
> url = {http://www.R-project.org},
> }
> With recent versions ISBN changed to 3-900051-07-0.
It changed with 2.0.0, which is not that recent ...
> Now I wonder if there is any canonical way to refer to R without
> the need to change R entry over and over. It would probably be the
> best just to add new entry for "new version" for R. Now the
> question is what is new version or when does ISBN number change?
The ISBN changes with every major version of R, i.e., it will change
next when 3.0.0 is released. We are already stretching the ISBN rules
to the limit (on the no-change-side) with that policy, and the
reason is exactly to make the reference more stable. But with a major
release we really need to assign a new ISBN.
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Citation through time
> On Tue, 12 Sep 2006 21:22:13 +0300 (EEST), > Ioannis Dimakos (ID) wrote: > Forgive me for being naive, > but I have not seen any reference where the ISBN was required. The apa > style that I use does not require the ISBN. It is not required for most citation *styles*. The main reason that we assigned an ISBN to R is that some people/journals/departments/... think that software cannot or should not be cited, and in that cases it often helps to have an ISBN, because it "looks more official". And the ISBN rules explicitly state that software should get an ISBN for full references. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave processes \Sexpr in commented LaTeX source (2.3.1patched and 2.4.0)
> On Tue, 19 Sep 2006 19:14:39 -0500,
> Marc Schwartz (MS) wrote:
> Hi all,
> On FC5, using:
> Version 2.3.1 Patched (2006-08-06 r38829)
> and today's
> R version 2.4.0 alpha (2006-09-19 r39397)
> with the following .Rnw file:
> \documentclass[10pt]{article}
> \begin{document}
>This line should print '2': \Sexpr{1 + 1}
> %% This line should NOT print '2': \Sexpr{1 + 1}
> \end{document}
> The \Sexpr in the second line is processed even though the line is
> commented. This results in the following .tex file content (in the case
> of R 2.4.0):
> \documentclass[10pt]{article}
> \usepackage{/home/marcs/R.Files/SourceCode/R-alpha/share/texmf/Sweave}
> \begin{document}
>This line should print '2': 2
> %% This line should NOT print '2': 2
> \end{document}
> Shouldn't Sweave just generally ignore commented LaTeX code? In
> reviewing Sweave.R I did not see a check for this, so perhaps there are
> circumstances where one wants a \Sexpr in commented LaTeX code
> processed. An example escapes me at the moment however.
Sweave does not parse the LaTeX part of the document at all (which
makes it a lot easier), all it does is looking for its own "magic
strings" and replacing those, wherever they might occur.
If we would start to respect comments, we would need a some kind of
parser for LaTeX, which we currently don't need ... and starting to
parse LaTeX would also open a can of worms of possible requests (what
to do with Sexpr inside verbatim, etc, etc).
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave processes \Sexpr in commented LaTeX source (2.3.1patched and 2.4.0)
> On Wed, 20 Sep 2006 10:07:26 -0700,
> Seth Falcon (SF) wrote:
> "Antonio, Fabio Di Narzo" <[EMAIL PROTECTED]> writes:
>> 2006/9/20, Seth Falcon <[EMAIL PROTECTED]>:
>>> Peter Dalgaard <[EMAIL PROTECTED]> writes:
>>> > ..not to mention TeX comments inside Sexpr (e.g. %*%...). Skipping
>>> > lines with % as the first character might be a viable compromise
>>> > though.
>>>
>>> +1. You could probably ignore any lines where the first
>>> non-whitespace char is '%'. But if that seems to risky, then only
>>> recognizing first-char-is-% seems a worthwhile heuristic.
>>>
>>> Another place where this has bitten people is when they do:
>>>
>>> %\usepackage{Sweave}
>>>
>>> Sweave picks that up and doesn't insert the usepackage line itself.
>>
>> I've found that extremely useful for sweaving Stex files which aren't
>> "master" files (i.e., only files to include in a main latex file).
>> Inserting '\usepackage{Sweave}' in each would result in a latex error.
>> So commenting it out is a useful workaround.
> Commenting it out _and_ having Sweave see it?
Yes, I actually do that quite often, e.g., when I have my own
definitions of the Sinput/Soutput/... environments in the document
preamble and don't want to use any Sweave style file.
Note that we recently had a thread on the \usepackage{Sweave} path
insertion problems in windows and as a result I will stop being
special about it at all, i.e., users will have to put a
\usepackage{Sweave} into their documents, and take care that latex
finds a version of it.
The thread was end of August and I didn't do it for 2.4 because I
didn't want to break all vignettes that close to a release. But I will
do for the 2.5 series once 2.4.0 is released.
Ad evaluation of \Sexpr{}: That can be considered a bug, hence I could
try a fix even in feature freeze. But as I will be offline for a week
starting tomorrow this will also have to wait until the 2.5 series (or
2.4.1, depending on the change).
My favorite would not be a separate option eval.Sexpr but eveluate
only when the global option for eval is true. Then an
\SweaveOpts{eval=false}
at any place in a document would stop all evalualtions, be it code
chunks (which do not override the default) or Sexpr. If somebody has
good useage for a separate option I could be convinced to have it,
otherwise I'll go for \Sexpr{} listening to the eval option.
Best,
Fritz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Where to put sgml file
> On Mon, 9 Oct 2006 11:46:51 -0400, > Gabor Grothendieck (GG) wrote: > I have a package that will have an sgml file. One of the demos in ./demo > will use it. Where should I put it? > I tried putting it in ./demo but it did not survive the build so > currently I put it in ./inst and it gets copied to the same level as the > DESCRIPTION file and the demo gets it from there. Is that right or > is there a better choice? I would probably use a directory "inst/sgml-files" (replace "sgml-files" by your favorite name which is not already used by R like "data") and place the file there. If it is a single file and no second file is on the horizon, then putting it directly into "inst" is also OK. > I assume I can't use ./data since its not in > the form that is directly readable as an R data file. exactly. best, fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9443)
> On Thu, 11 Jan 2007 15:07:00 +0100 (CET),
> ahenningsen (a) wrote:
> Full_Name: Arne Henningsen
> Version: 2.4.0
> OS: Linux
> Submission from: (NULL) (134.245.140.242)
> Sweave does not allow line breaks after forward slashes ("/"). This might
lead
> to a long "substring" of a command that cannot be wrapped. Hence, Sweave
either
> keeps this long "substring" in the current line and produces a too long
line or
> it moves the entire "substring" in the following line and leaves the current
> line rather empty. This problem can be solved if Sweave is allowed to
introduce
> line breaks after forward slashes. (I guess that this problem can also be
solved
> if parse() adds a blank after a forward slash.)
> Example:
> The following expression cannot be wrapped by Sweave:
> mean(myDataframe$myFirstVariable)/mean(myDataframe$mySecondVariable)
In R 2.5.0 you can use Sweave option keep.source=TRUE to keep the
original formatting of source code, including all indentation and line
breaks -> does this solve your problem?
Best,
Fritz Leisch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: Sweave: allow line breaks after forward slashes (PR#9444)
> On Thu, 11 Jan 2007 15:07:00 +0100 (CET),
> ahenningsen (a) wrote:
> Full_Name: Arne Henningsen
> Version: 2.4.0
> OS: Linux
> Submission from: (NULL) (134.245.140.242)
> Sweave does not allow line breaks after forward slashes ("/"). This might
lead
> to a long "substring" of a command that cannot be wrapped. Hence, Sweave
either
> keeps this long "substring" in the current line and produces a too long
line or
> it moves the entire "substring" in the following line and leaves the current
> line rather empty. This problem can be solved if Sweave is allowed to
introduce
> line breaks after forward slashes. (I guess that this problem can also be
solved
> if parse() adds a blank after a forward slash.)
> Example:
> The following expression cannot be wrapped by Sweave:
> mean(myDataframe$myFirstVariable)/mean(myDataframe$mySecondVariable)
In R 2.5.0 you can use Sweave option keep.source=TRUE to keep the
original formatting of source code, including all indentation and line
breaks -> does this solve your problem?
Best,
Fritz Leisch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [OT] old news on the home page
>>>>> On Mon, 15 Jan 2007 17:01:47 +0100, >>>>> Antonio, Fabio Di Narzo (AFDN) wrote: > Hi all. > I've noticed that on the R homepage: > http://www.r-project.org/ > one can read, as the latest news: > " R version 2.4.0 has been released on 2006-10-03." > and can't find any citation of the 2.4.1 release of the last 18 december. Thanks a lot for the hint, fixed in SVN (will automatically go online later today). Best, Fritz -- ------- Prof. Dr. Friedrich Leisch Institut für Statistik Tel: (+49 89) 2180 3165 Ludwig-Maximilians-Universität Fax: (+49 89) 2180 5308 Ludwigstraße 33 D-80539 München http://www.stat.uni-muenchen.de/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
