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

From: Peter Dalgaard <>
Date: Wed, 07 Nov 2007 11:51:01 +0100

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
~~~~~~~~~~ - (                  FAX: (+45) 35327907

______________________________________________ mailing list
Received on Wed 07 Nov 2007 - 10:55:39 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Wed 07 Nov 2007 - 11:30:15 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.