[Rd] Saving Graphics File as .ps or .pdf (PR#10403)

Peter Dalgaard P.Dalgaard at biostat.ku.dk
Wed Nov 7 11:51:01 CET 2007

Jari Oksanen wrote:
> On Wed, 2007-11-07 at 10:51 +0100, Simone Giannerini wrote:
>> [snip] (this is from pd = Peter Dalgaard)
>>> Maybe, but given the way things have been working lately, it might be
>>> better to emphasize
>>> (a) check the mailinglists
>>> (b) try R-patched
>>> (c) if in doubt, ask, rather than report as bug
>>> (Ideally, people would try the prerelease versions and problems like
>>> this would be caught before the actual release, but it seems that they
>>> prefer treating x.y.0 as a beta release...)
>> I am sorry but I do not agree with point (b) for the very simple fact
>> that the average Windows user do not know how to compile the source
>> code and might not even want to learn how to do it. The point is that
>> since (if I am correct) the great majority of  R users go Windows you
>> would miss an important part of potential bug reports by requiring
>> point (b) whereas (a) and (c) would suffice IMHO.
>> Maybe if there were Win binaries of the prerelease version available
>> some time before the release you would get much more feedback but I am
>> just guessing.
> First I must say that patched Windows binaries are available from CRAN
> with one extra click -- Linux and poor MacOS users must use 'svn co' to
> check out the patched version from the repository and compile from the
> sources. The attribute "poor" for MacOS users was there because this is
> a bigger step for Mac users than Linux users (who can easily get and
> install all tools they need and tend to have a different kind of
> mentality). 
Actually, they can download


They do have to build it (and know how to) though.

(Fedora incorporated patches in their RPM updates for a while, which I
was beginning to believe was a good idea, all things considered, but
they haven't done it (yet?) for 2.6.0.)

> Then I must say that I do not like this policy either. I think that is
> fair to file a bug report against the latest release version in good
> faith without being chastised and condemned. I know (like pd says above)
> that some people really do treat x.y.0 as beta releases: a friend of
> mine over here even refuses to install R x.x.0 versions just for this
> reason (in fact, he's pd's mate, too, but perhaps pd can talk him over
> to try x.x.0 versions). Filing a bug report against latest x.x.1
> shouldn't be too bad either.
Of course that strategy just means that .0 becomes the alpha release and
.1 the beta....

> I guess the problem here is that R bug reports are linked to the Rd
> mailing list, and reports on "alredy fixed" bugs really are irritating.
> In more loosely connected bug reporting systems you simply could mark a
> bug as a duplicate of #xxxx and mark it as resolved without generating
> awfully lot of mail. Then it would be humanly possible to adopt a more
> neutral way of answering to people who reported bugs in latest releases.
> Probably that won't happen in the current environment.
Someone still needs to do that, manually. But yes, a new bug tracker has
been on the wish list for a while.
It is not entirely trivial to set one up, though.

   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907

More information about the R-devel mailing list