Re: [Rd] R 2.1.1 slated for June 20
On Tue, 2005-06-14 at 17:07 -0500, Marc Schwartz wrote:
> On Tue, 2005-06-14 at 23:52 +0200, Peter Dalgaard wrote:
> > Marc Schwartz <[EMAIL PROTECTED]> writes:
> >
> > > On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> > > > On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> > > >
> > > > > The next version of R will be released (barring force majeure) on June
> > > > > 20th, with beta versions available starting Monday.
> > > > >
> > > > > Please do check them on your system *before* the release this time...
> > > >
> > > > Some things which it would be particularly helpful to have tested:
> > >
> > >
> > > > - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3? (These
> > > >often show up problems with bugs in the pre-release versions of
> > > >components such as X11 and compilers.)
> > >
> > >
> > > Just as a quick heads up, I installed FC4 Release ("Stentz") late
> > > yesterday.
> > >
> > > R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
> > >
> > > $ gcc --version
> > > gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
> > >
> > > and make check-all passes with no problems.
> > >
> > > I have also installed all CRAN packages that do not require other 3rd
> > > party drivers, etc. and there were no observed errors in those cases.
> > >
> > > So far, so good.
> > >
> > > If anything comes up, I will post a follow up.
> > >
> > > Best regards,
> > >
> > > Marc Schwartz
> >
> > Yep. Just tried the same on AMD64 (I had a bit of a fight converting
> > my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
> > A couple of f95 warnings whooshed by during the compile, that was all.
> >
> > By the way, I noticed that you can now "yum install R R-devel" and get
> > everything straight from Fedora Extras.
>
> Yep. Tom "Spot" Callaway is the FE maintainer for R.
I had a look at his RPM last night. It includes a patch for gcc4, which
fails to build R with the fairly aggressive optimizations used by
rpmbuild. ("-O2 -D_FORTIFY_SOURCE=2" will reproduce the bug, IIRC, but
I'm not upgrading my work PC just yet, so I can't be sure). I folded
this into R-patched. It's a shame he didn't send a bug report or, if he
did, I missed it.
I also note he is using the patch that sets LANG=C, which is obsolete
now that R supports utf-8 locales. I'll write to him (cc Marc) to let
him know about these changes.
The RedHat RPMS also use the shared library version of R. I've been
thinking about making this change myself, despite the substantial speed
penalty, since I've seen a growing number of people recompiling to get
the shared library. The Red Hat choice forces my hand though: I don't
want people upgrading from their R 2.1.0 to my R 2.1.1 and finding their
installed packages don't work anymore. The $64,000 question is how many
people are going to care about that 15-20% decrease in speed. Speak up
now if it concerns you.
> A lot of things for FC 4 have been moved to Extras and there are of
> course new things (like R) there as well. The restrictions on non-GPL
> components is still there, so things like MP3 functionality is available
> via third party repos such as FreshRPMS, Livna, etc.
>
> This was a "balancing" act between trying to reduce (manage) the size of
> the main distro and reducing real or perceived redundancies in packages.
>
> So, for example:
>
> 1. Include OO.org in Core, but move Gnumeric to Extras
>
> 2. Include Emacs in Core, but move XEmacs to Extras
>
> Needless to say, that resulted in "emotional" discussions.
This underscores the fact Fedora, despite claiming to be a community
project, is essentially Red Hat's rolling beta programme, and so must be
more focused and less inclusive than Debian. (Just an observation. I
don't want to start a discussion on FOSS politics)
Martyn
---
This message and its attachments are strictly confidential. If you are
not the intended recipient of this message, please immediately notify
the sender and delete it. Since its integrity cannot be guaranteed,
its content cannot involve the sender's responsibility. Any misuse,
any disclosure or publication of its content, either whole or partial,
is prohibited, exception made of formally approved use
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
On Thu, 16 Jun 2005, Martyn Plummer wrote:
> On Tue, 2005-06-14 at 17:07 -0500, Marc Schwartz wrote:
>> On Tue, 2005-06-14 at 23:52 +0200, Peter Dalgaard wrote:
>>> Marc Schwartz <[EMAIL PROTECTED]> writes:
>>>
On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> On Fri, 10 Jun 2005, Peter Dalgaard wrote:
>
>> The next version of R will be released (barring force majeure) on June
>> 20th, with beta versions available starting Monday.
>>
>> Please do check them on your system *before* the release this time...
>
> Some things which it would be particularly helpful to have tested:
> - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3? (These
>often show up problems with bugs in the pre-release versions of
>components such as X11 and compilers.)
Just as a quick heads up, I installed FC4 Release ("Stentz") late
yesterday.
R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
$ gcc --version
gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
and make check-all passes with no problems.
I have also installed all CRAN packages that do not require other 3rd
party drivers, etc. and there were no observed errors in those cases.
So far, so good.
If anything comes up, I will post a follow up.
Best regards,
Marc Schwartz
>>>
>>> Yep. Just tried the same on AMD64 (I had a bit of a fight converting
>>> my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
>>> A couple of f95 warnings whooshed by during the compile, that was all.
>>>
>>> By the way, I noticed that you can now "yum install R R-devel" and get
>>> everything straight from Fedora Extras.
>>
>> Yep. Tom "Spot" Callaway is the FE maintainer for R.
>
> I had a look at his RPM last night. It includes a patch for gcc4, which
> fails to build R with the fairly aggressive optimizations used by
> rpmbuild. ("-O2 -D_FORTIFY_SOURCE=2" will reproduce the bug, IIRC, but
> I'm not upgrading my work PC just yet, so I can't be sure). I folded
> this into R-patched. It's a shame he didn't send a bug report or, if he
> did, I missed it.
Looks to me that this is bug in gcc4, not in R. (It's not actually an
optimization.) I've resisted making any such changes until gcc 4.0.1 is
released - and that is held up on some outstanding bug fixes.
(BTW, it is a really good idea to put a comment in the file as to why
unnecessary parentheses have been added.)
It's a shame FC4 does not contain a well-tested high-quality compiler like
3.4.4 or 3.3.6, especially a well-tested high-quality Fortran compiler.
> I also note he is using the patch that sets LANG=C, which is obsolete
> now that R supports utf-8 locales. I'll write to him (cc Marc) to let
> him know about these changes.
>
> The RedHat RPMS also use the shared library version of R. I've been
> thinking about making this change myself, despite the substantial speed
> penalty, since I've seen a growing number of people recompiling to get
> the shared library. The Red Hat choice forces my hand though: I don't
> want people upgrading from their R 2.1.0 to my R 2.1.1 and finding their
> installed packages don't work anymore. The $64,000 question is how many
> people are going to care about that 15-20% decrease in speed. Speak up
> now if it concerns you.
Well, if they do they will also care about the 5-10% or so that gcc4 costs
them over 3.4.4 and so will not want your RPM.
BTW, I find 15-20% on i686, 10-15 on x86_64, and I have no idea about PPC.
(That warning about
dotcode.c:96: warning: ISO C forbids assignment between function pointer and
`void *'
is supposed to be serious on PPC64 where a function pointer is really a
different sort of object. FC4 claims to support 64-bit PPC, but it is not
clear that this is actually a 64-bit OS.) gcc4 has features we can use to
narrow the gap but first it has to work reliably.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
Martyn Plummer <[EMAIL PROTECTED]> writes:
> On Tue, 2005-06-14 at 17:07 -0500, Marc Schwartz wrote:
> > On Tue, 2005-06-14 at 23:52 +0200, Peter Dalgaard wrote:
> > > Marc Schwartz <[EMAIL PROTECTED]> writes:
> > >
> > > > On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> > > > > On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> > > > >
> > > > > > The next version of R will be released (barring force majeure) on
> > > > > > June
> > > > > > 20th, with beta versions available starting Monday.
> > > > > >
> > > > > > Please do check them on your system *before* the release this
> > > > > > time...
> > > > >
> > > > > Some things which it would be particularly helpful to have tested:
> > > >
> > > >
> > > > > - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3?
> > > > > (These
> > > > >often show up problems with bugs in the pre-release versions of
> > > > >components such as X11 and compilers.)
> > > >
> > > >
> > > > Just as a quick heads up, I installed FC4 Release ("Stentz") late
> > > > yesterday.
> > > >
> > > > R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
> > > >
> > > > $ gcc --version
> > > > gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
> > > >
> > > > and make check-all passes with no problems.
> > > >
> > > > I have also installed all CRAN packages that do not require other 3rd
> > > > party drivers, etc. and there were no observed errors in those cases.
> > > >
> > > > So far, so good.
> > > >
> > > > If anything comes up, I will post a follow up.
> > > >
> > > > Best regards,
> > > >
> > > > Marc Schwartz
> > >
> > > Yep. Just tried the same on AMD64 (I had a bit of a fight converting
> > > my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
> > > A couple of f95 warnings whooshed by during the compile, that was all.
> > >
> > > By the way, I noticed that you can now "yum install R R-devel" and get
> > > everything straight from Fedora Extras.
> >
> > Yep. Tom "Spot" Callaway is the FE maintainer for R.
>
> I had a look at his RPM last night. It includes a patch for gcc4, which
> fails to build R with the fairly aggressive optimizations used by
> rpmbuild. ("-O2 -D_FORTIFY_SOURCE=2" will reproduce the bug, IIRC, but
> I'm not upgrading my work PC just yet, so I can't be sure). I folded
> this into R-patched. It's a shame he didn't send a bug report or, if he
> did, I missed it.
Thanks for looking into this. Do you know what is the time frame for
getting a new version into FC-E? Do we actually need separate CRAN
versions any more? BTW, I noticed that the Fedora RPMs depend on a
blas RPM. Do you have any inkling about what that implies? (I've never
quite understood whether there is a "right" way to use a machine
specific BLAS in concert with a packaging system).
> I also note he is using the patch that sets LANG=C, which is obsolete
> now that R supports utf-8 locales. I'll write to him (cc Marc) to let
> him know about these changes.
>
> The RedHat RPMS also use the shared library version of R. I've been
> thinking about making this change myself, despite the substantial speed
> penalty, since I've seen a growing number of people recompiling to get
> the shared library. The Red Hat choice forces my hand though: I don't
> want people upgrading from their R 2.1.0 to my R 2.1.1 and finding their
> installed packages don't work anymore. The $64,000 question is how many
> people are going to care about that 15-20% decrease in speed. Speak up
> now if it concerns you.
What is a good way to measure that? For hardcore numerics, it is
certainly much less than 15% on the AMD64:
# RPM:
> system.time(solve(matrix(rnorm(1e6),1e3)))
[1] 8.64 0.15 8.86 0.00 0.00
# My private build
[EMAIL PROTECTED] ~]$ r-patched/BUILD/bin/R -q
> system.time(solve(matrix(rnorm(1e6),1e3)))
[1] 8.49 0.15 8.64 0.00 0.00
(and there is a substantial replication variation on those numbers).
For more integer-bound stuff like
system.time(p <- replicate(1,t.test(rexp(25),mu=1)$p.value))
I get about 14.1s with the RPM and 11.7s with my build.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
On Thu, 2005-06-16 at 12:41 +0200, Martyn Plummer wrote:
> On Tue, 2005-06-14 at 17:07 -0500, Marc Schwartz wrote:
> > On Tue, 2005-06-14 at 23:52 +0200, Peter Dalgaard wrote:
> > > Marc Schwartz <[EMAIL PROTECTED]> writes:
> > >
> > > > On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> > > > > On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> > > > >
> > > > > > The next version of R will be released (barring force majeure) on
> > > > > > June
> > > > > > 20th, with beta versions available starting Monday.
> > > > > >
> > > > > > Please do check them on your system *before* the release this
> > > > > > time...
> > > > >
> > > > > Some things which it would be particularly helpful to have tested:
> > > >
> > > >
> > > > > - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3?
> > > > > (These
> > > > >often show up problems with bugs in the pre-release versions of
> > > > >components such as X11 and compilers.)
> > > >
> > > >
> > > > Just as a quick heads up, I installed FC4 Release ("Stentz") late
> > > > yesterday.
> > > >
> > > > R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
> > > >
> > > > $ gcc --version
> > > > gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
> > > >
> > > > and make check-all passes with no problems.
> > > >
> > > > I have also installed all CRAN packages that do not require other 3rd
> > > > party drivers, etc. and there were no observed errors in those cases.
> > > >
> > > > So far, so good.
> > > >
> > > > If anything comes up, I will post a follow up.
> > > >
> > > > Best regards,
> > > >
> > > > Marc Schwartz
> > >
> > > Yep. Just tried the same on AMD64 (I had a bit of a fight converting
> > > my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
> > > A couple of f95 warnings whooshed by during the compile, that was all.
> > >
> > > By the way, I noticed that you can now "yum install R R-devel" and get
> > > everything straight from Fedora Extras.
> >
> > Yep. Tom "Spot" Callaway is the FE maintainer for R.
>
> I had a look at his RPM last night. It includes a patch for gcc4, which
> fails to build R with the fairly aggressive optimizations used by
> rpmbuild. ("-O2 -D_FORTIFY_SOURCE=2" will reproduce the bug, IIRC, but
> I'm not upgrading my work PC just yet, so I can't be sure). I folded
> this into R-patched. It's a shame he didn't send a bug report or, if he
> did, I missed it.
>
> I also note he is using the patch that sets LANG=C, which is obsolete
> now that R supports utf-8 locales. I'll write to him (cc Marc) to let
> him know about these changes.
>
> The RedHat RPMS also use the shared library version of R. I've been
> thinking about making this change myself, despite the substantial speed
> penalty, since I've seen a growing number of people recompiling to get
> the shared library. The Red Hat choice forces my hand though: I don't
> want people upgrading from their R 2.1.0 to my R 2.1.1 and finding their
> installed packages don't work anymore. The $64,000 question is how many
> people are going to care about that 15-20% decrease in speed. Speak up
> now if it concerns you.
Martyn,
>From what I can tell, there is only one reason that the FC-E R RPM is
available as a shared library:
Tom had made the gnomeGUI CRAN package available as an RPM in FC-E,
which of course requires the above:
http://fedoraproject.org/extras/4/i386/repodata/repoview/R-gnomeGUI-0-2.1.0-4.html
I would defer to the opinion of others here, but given the rather
limited functionality of the R GNOME GUI and that not much if any work
is presently being done on it (is that correct?), does Tom's approach
really make sense?
Tom has also made RScaLAPACK available, but unless I am missing
something, I do not see a requirement that R be compiled as a shared
library for that package:
http://fedoraproject.org/extras/4/i386/repodata/repoview/R-RScaLAPACK-0-0.4.0-12.fc4.html
I am unclear as to the criteria for his package selection for FC-E and
what his future plans might be with respect to other CRAN packages being
made available via FC-E repos.
Perhaps Dirk (cc:'d here) and others on the Debian side of things have
some thoughts here. I know that there were exchanges in the past
regarding how to handle R and CRAN packages that were available directly
and/or from apt repos as .debs, relative to conflicts, etc. I am not
sure if anything was ever resolved on those issues. If they have some
approaches that make sense, it would seem logical to leverage their
experience.
> > A lot of things for FC 4 have been moved to Extras and there are of
> > course new things (like R) there as well. The restrictions on non-GPL
> > components is still there, so things like MP3 functionality is available
> > via third party repos such as FreshRPMS, Livna, etc.
> >
> > This was a "balancing" act between trying to reduce (manage) the size of
> > the main distro and reducing real or perceived redundancies in packages.
> >
> > So, for example
Re: [Rd] R 2.1.1 slated for June 20
On Thu, 16 Jun 2005, Marc Schwartz wrote: >> From what I can tell, there is only one reason that the FC-E R RPM is > available as a shared library: > > Tom had made the gnomeGUI CRAN package available as an RPM in FC-E, > which of course requires the above: > > http://fedoraproject.org/extras/4/i386/repodata/repoview/R-gnomeGUI-0-2.1.0-4.html > > I would defer to the opinion of others here, but given the rather > limited functionality of the R GNOME GUI and that not much if any work > is presently being done on it (is that correct?), does Tom's approach > really make sense? No work is being done on it. It remains only as an example of a console front-end. Brian -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
On Thu, 2005-06-16 at 15:23 +0100, Prof Brian Ripley wrote: > On Thu, 16 Jun 2005, Marc Schwartz wrote: > > >> From what I can tell, there is only one reason that the FC-E R RPM is > > available as a shared library: > > > > Tom had made the gnomeGUI CRAN package available as an RPM in FC-E, > > which of course requires the above: > > > > http://fedoraproject.org/extras/4/i386/repodata/repoview/R-gnomeGUI-0-2.1.0-4.html > > > > I would defer to the opinion of others here, but given the rather > > limited functionality of the R GNOME GUI and that not much if any work > > is presently being done on it (is that correct?), does Tom's approach > > really make sense? > > No work is being done on it. It remains only as an example of a console > front-end. > > Brian That being the confirmed case, it seems reasonable to facilitate Tom's making an informed decision as to the pros and cons of his approach and that his choice is askew from a "default" R configuration. Needless to say, his choice, presumably based upon the inclusion of the gnomeGUI package, is to an extent exclusionary to KDE and other DE users who will (unknowingly) pay a defacto performance price if installing R via FC-E. Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
On Thu, 2005-06-16 at 12:41 +0100, Prof Brian Ripley wrote:
> On Thu, 16 Jun 2005, Martyn Plummer wrote:
>
> > On Tue, 2005-06-14 at 17:07 -0500, Marc Schwartz wrote:
> >> On Tue, 2005-06-14 at 23:52 +0200, Peter Dalgaard wrote:
> >>> Marc Schwartz <[EMAIL PROTECTED]> writes:
> >>>
> On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> > On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> >
> >> The next version of R will be released (barring force majeure) on June
> >> 20th, with beta versions available starting Monday.
> >>
> >> Please do check them on your system *before* the release this time...
> >
> > Some things which it would be particularly helpful to have tested:
>
>
> > - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3? (These
> >often show up problems with bugs in the pre-release versions of
> >components such as X11 and compilers.)
>
>
> Just as a quick heads up, I installed FC4 Release ("Stentz") late
> yesterday.
>
> R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
>
> $ gcc --version
> gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
>
> and make check-all passes with no problems.
>
> I have also installed all CRAN packages that do not require other 3rd
> party drivers, etc. and there were no observed errors in those cases.
>
> So far, so good.
>
> If anything comes up, I will post a follow up.
>
> Best regards,
>
> Marc Schwartz
> >>>
> >>> Yep. Just tried the same on AMD64 (I had a bit of a fight converting
> >>> my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
> >>> A couple of f95 warnings whooshed by during the compile, that was all.
> >>>
> >>> By the way, I noticed that you can now "yum install R R-devel" and get
> >>> everything straight from Fedora Extras.
> >>
> >> Yep. Tom "Spot" Callaway is the FE maintainer for R.
> >
> > I had a look at his RPM last night. It includes a patch for gcc4, which
> > fails to build R with the fairly aggressive optimizations used by
> > rpmbuild. ("-O2 -D_FORTIFY_SOURCE=2" will reproduce the bug, IIRC, but
> > I'm not upgrading my work PC just yet, so I can't be sure). I folded
> > this into R-patched. It's a shame he didn't send a bug report or, if he
> > did, I missed it.
>
> Looks to me that this is bug in gcc4, not in R. (It's not actually an
> optimization.) I've resisted making any such changes until gcc 4.0.1 is
> released - and that is held up on some outstanding bug fixes.
>
> (BTW, it is a really good idea to put a comment in the file as to why
> unnecessary parentheses have been added.)
Mea culpa.
I have asked Tom Callaway whether this was intended as a bug-fix for R
or a workaround.
> It's a shame FC4 does not contain a well-tested high-quality compiler like
> 3.4.4 or 3.3.6, especially a well-tested high-quality Fortran compiler.
That's not what Fedora is for, as I was discussing with Marc. Fedora
users are willing (although perhaps unthinking) participants in Red
Hat's beta testing cycle. By the time the bleeding-edge technology in
Fedora gets to Red Hat's paying customers, it is well-tested and high-
quality.
> > I also note he is using the patch that sets LANG=C, which is obsolete
> > now that R supports utf-8 locales. I'll write to him (cc Marc) to let
> > him know about these changes.
> >
> > The RedHat RPMS also use the shared library version of R. I've been
> > thinking about making this change myself, despite the substantial speed
> > penalty, since I've seen a growing number of people recompiling to get
> > the shared library. The Red Hat choice forces my hand though: I don't
> > want people upgrading from their R 2.1.0 to my R 2.1.1 and finding their
> > installed packages don't work anymore. The $64,000 question is how many
> > people are going to care about that 15-20% decrease in speed. Speak up
> > now if it concerns you.
>
> Well, if they do they will also care about the 5-10% or so that gcc4 costs
> them over 3.4.4 and so will not want your RPM.
That would depend on how I compile it. I'm quite happy to maintain an
R-static RPM for people who feel the need for speed. But I don't know if
there is a demand. I see that the Debian package uses the shared
library.
> BTW, I find 15-20% on i686, 10-15 on x86_64, and I have no idea about PPC.
> (That warning about
>
> dotcode.c:96: warning: ISO C forbids assignment between function pointer and
> `void *'
>
> is supposed to be serious on PPC64 where a function pointer is really a
> different sort of object. FC4 claims to support 64-bit PPC, but it is not
> clear that this is actually a 64-bit OS.) gcc4 has features we can use to
> narrow the gap but first it has to work reliably.
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,
Re: [Rd] a bug in glm.fit() (PR#7947)
On Thu, 2005-06-16 at 07:06 +0100, Prof Brian Ripley wrote: > What is the bug? > > This is the same model: the `intercept' term affects the null model, not > the actual model. Just look at all the output. I think the documentation is misleading (On a related issue, it still refers to the defunct glm.fit.null() function). I'll fix it. Luke, you be using glm() instead of glm.fit(). > On Thu, 16 Jun 2005 [EMAIL PROTECTED] wrote: > > > glm.fit() gave me the same AIC's regardless of TRUE or FALSE intercept > > option. > > > >> myX <- as.matrix(1:10) > >> myY <- 3+5*myX > >> foo <- glm.fit(x=myX, y=myY, family = gaussian(link = "identity"), > >> intercept=TRUE) > >> foo$aic > > [1] 38.94657 > >> foo <- glm.fit(x=myX, y=myY, family = gaussian(link = "identity"), > >> intercept=FALSE) > >> foo$aic > > [1] 38.94657 > >> AIC(lm(myY~0+myX, data=data.frame(myY,myX))) > > [1] 38.94657 > >> AIC(lm(myY~1+myX, data=data.frame(myY,myX))) > > [1] -650.9808 > --- This message and its attachments are strictly confidential. If you are not the intended recipient of this message, please immediately notify the sender and delete it. Since its integrity cannot be guaranteed, its content cannot involve the sender's responsibility. Any misuse, any disclosure or publication of its content, either whole or partial, is prohibited, exception made of formally approved use __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] motivation for setRepositories and chooseCRANmirror
I have some questions and observations about these:
Will these replace manually setting options(CRAN), which doesn't work in
R-2.1.0?
In R-2.1.0, setRepositories() looks to see if options("repos") contains
a CRAN entry and will not override that CRAN entry even if the
$R_HOME/etc/repositories file (which setRepositories reads from)
contains a CRAN entry. Why is this? The user could easily set
options("repos") without the help of this function anyway? And
chooseCRANmirror() obviously sets the CRAN entry correctly.
I've checked the latest nightly tarball, R-devel_2005-06-15.tar.gz, and
this observations persists.
I also observe that the R-2.1.0 Rprofile in the base package sets
options(repos=c(CRAN="@CRAN@")), so it seems that the only way to set
the CRAN repository entry is either with chooseCRANmirror() or manually
setting options("repos") or options("CRAN"). If this was not the case,
then setRepositories() would choose the CRAN entry from
$R_HOME/etc/repositories.
In R-2.1.0 and in R-devel_2005-06-15.tar.gz, the R-admin manual suggests
that for packages to be downloaded and installed within R should set
options(CRAN = "http://cran.us.r-project.org/";). Will this be changed to
calling chooseCRANmirror()?
From an administrator's point of view, I would like to have the CRAN
option set automatically on R startup for ALL users. That way I don't
have to set this option before calling update.packages().
--
Jeffrey Horner Computer Systems Analyst School of Medicine
615-322-8606 Department of Biostatistics Vanderbilt University
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Tapes... DVDs... Now this...
Hey, Then I started 'teaching'. You know, I'm a good teacher. (Well, maybe just an average teacher, but you get the jist). I know what good teachers do. Or I thought I did. I sat with the children at the computer. When they pressed the IntelliKeys' keyboard or the Touch Window' and the computer said the word, I repeated the word and then expanded on the word. After they had pressed the same word several times, I said, "That's right, that's a cat, can you find the dog?? Suddenly, I would see the child's back get stiff, and before you knew it, he got up and left the computer. I didn't understand. Just a few seconds ago, he loved it. What happened? If you can't describe what you are doing as a process, you don't know what you're doing.W. Edwards Deming Thanks Alot, Bianca Kennedy [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Tapes... DVDs... Now this... (PR#7950)
Hey, Then I started 'teaching'. You know, I'm a good teacher. (Well, maybe just an average teacher, but you get the jist). I know what good teachers do. Or I thought I did. I sat with the children at the computer. When they pressed the IntelliKeys' keyboard or the Touch Window' and the computer said the word, I repeated the word and then expanded on the word. After they had pressed the same word several times, I said, "That's right, that's a cat, can you find the dog?? Suddenly, I would see the child's back get stiff, and before you knew it, he got up and left the computer. I didn't understand. Just a few seconds ago, he loved it. What happened? If you can't describe what you are doing as a process, you don't know what you're doing.W. Edwards Deming Thanks Alot, Bianca Kennedy [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] DispatchOrEval missing in do_isfinite and do_isinfinite (PR#7951)
Full_Name: Lars Hansen
Version: 2.1.0
OS: SunOS 5.8
Submission from: (NULL) (207.66.36.189)
Hi,
S4 method displacth does not work for the two generic functions 'is.finite' and
'is.infinite'. It turns out that the C functions 'do_isfinite' and
'do_isinfinite' in src/main/coerce.c are missing a call to 'DispatchOrEval' (see
do_isnan). Added in the call fixed the problem. My functions no look like this:
Form coerce.c:
SEXP do_isfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
{
SEXP ans, x, names, dims;
int i, n;
if (DispatchOrEval(call, op, "is.finite", args, rho, &ans, 1, 1))
return(ans);
checkArity(op, args);
...
SEXP do_isinfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
{
SEXP ans, x, names, dims;
double xr, xi;
int i, n;
if (DispatchOrEval(call, op, "is.infinite", args, rho, &ans, 1, 1))
return(ans);
checkArity(op, args);
...
Thanks you,
Lars
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 2.1.0a for Macs (PR#7952)
I am writing regarding serious problems that a number of researchers at a workshop held by the Smithsonian Tropical Research Institute are encountering with the most recent R version for Macs (the patched version of 2.1.0 (2.1.0a) that you indicate should be used over 2.1.0). The following problems are not specific to my computer but are being experienced by ALL Mac users at this workshop running 2.1.0a to varying degrees. I installed the program about a week ago and immediately I started getting a warning messages particularly when browsing my files using ls(), search(), gc(), etc. 2.1.0a automatically adds an open parentheses at the end of any command requiring () (only intermittently, however) and then generates a warning in red. I am afraid that I do not have the warning because R no longer will open on my computer without reinstallation so I am forced to use a PC. The same warning message has been posted by one other on the help email list. More recently, R has begun to crash for no particular reason (no large program running). Often when I then try to restart R 2.1.0a crashes during start up and in order to get it functioning again I have to reinstall! The first time this happened I decided to go back to an earlier version of R that I knew would be stable but following binary compilation no gui is installed on my computer and I can't run the program. The only version my computer can now install properly is 2.1.0a but as described above the problems with the program prohibit me from using it. If you could please advise on how to deal with these problems (particularly the corruption of my system by 2.1.0a) all the Mac users at this conference would be appreciative. Jennifer Baltzer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 2.1.0a for Macs (PR#7952)
On Jun 16, 2005, at 5:30 PM, [EMAIL PROTECTED] wrote: > I installed the program about a week ago and immediately I started > getting a warning messages particularly when browsing my files > using ls(), search(), gc(), This was fixed in R.app build 1564 and was mentioned several times on the Mac list. It is recommended to update your R.app. If you have problems with the most recent version (as of today it's build 1596), please let us know. > More recently, R has begun to crash for no particular reason (no > large program running). Often when I then try to restart R 2.1.0a > crashes during start up and in order to get it functioning again I > have to reinstall! Can you, please, send us the crash report and/or the console output? Without any evidence reports like yours are pretty much useless (please read the documentation and FAQ!). Also note that R 2.1.1 will be released really soon so it's important to report bugs using R 2.1.1 beta and not old versions. > The first time this happened I decided to go back to an earlier > version of R that I knew would be stable but following binary > compilation no gui is installed on my computer and I can't run the > program. What do you mean by "binary compilation" - if you feel like installing an older version all you have to do is to get the 2.1.0 image and install it. However, I doubt that this will solve any problems, but it's completely legal to do so. You can also safely use older versions of R.app if you want - 2.1.0 and 2.1.0a are by definition binary compatible. R itself didn't change substantially between 2.1.0 and 2.1.0a (only a couple of bugs were fixed, most notably package installation). What did change was R.app and as I already mentioned there are good reasons for using the most recent version. > If you could please advise on how to deal with these problems > (particularly the corruption of my system by 2.1.0a) You didn't mention any system corruption so far - you'll have to explain this a bit ... Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R worked once, now will not open. Works in console, but won't graph. (PR#7953)
Full_Name: Richard Zur Version: 2.1.0a OS: 10.3.9 Submission from: (NULL) (67.176.250.164) I erased R 2.0.1 (the R.app and the framework) and installed R 2.1.0a. I ran it once, then shut down without saving the workspace. Now it doesn't start at all. I've erased it a couple of times and re-installed (not installing the libraries I use, coda, MCMCpack, MASS and bayesm) but the same problem arises. Date/Time: 2005-06-16 20:27:57 -0500 OS Version: 10.3.9 (Build 7W98) Report Version: 2 Command: R Path:/Applications/R.app/Contents/MacOS/R Version: 1.11 (1.11) PID: 1605 Thread: 0 Exception: EXC_BREAKPOINT (0x0006) Code[0]:0x0001 Code[1]:0x9023dc44 Thread 0 Crashed: 0 com.apple.CoreFoundation0x9023dc44 __HALT + 0 1 com.apple.CoreFoundation0x901c2164 CFDictionaryGetValue + 0xec 2 com.apple.Foundation0x90a290d4 +[NSLanguageContext _alternateICUValueForKey:] + 0x48 3 com.apple.Foundation0x90a2bc8c -[NSUserDefaults objectForKey:] + 0x30 4 com.apple.Foundation0x90ab49dc -[NSUserDefaults dataForKey:] + 0x20 5 org.R-project.R 0x0001cc2c +[Preferences unarchivedObjectForKey:withDefault:] + 0x48 6 org.R-project.R 0xb740 -[RController updatePreferences] + 0xe8 7 org.R-project.R 0x36a4 -[RController awakeFromNib] + 0x16c 8 com.apple.Foundation0x90a5f0e8 -[NSSet makeObjectsPerformSelector:] + 0xa4 9 com.apple.AppKit0x92ea2150 -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] + 0x358 10 com.apple.AppKit0x92f93c2c loadNib + 0xfc 11 com.apple.AppKit0x92eeae24 +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] + 0x2e8 12 com.apple.AppKit0x92f69d28 +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] + 0x9c 13 com.apple.AppKit0x92f7b51c +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 0x174 14 com.apple.AppKit0x92f69b90 NSApplicationMain + 0x174 15 org.R-project.R 0x2ba0 _start + 0x188 (crt.c:267) 16 dyld0x8fe1a278 _dyld_start + 0x64 PPC Thread State: srr0: 0x9023dc44 srr1: 0x0202f030vrsave: 0x cr: 0x22000248 xer: 0x0007 lr: 0x901c2d08 ctr: 0x9023dc44 r0: 0x901c2d08 r1: 0xb710 r2: 0xa01c2be8 r3: 0xbff0 r4: 0x r5: 0xbff0 r6: 0x003eadd0 r7: 0x r8: 0x r9: 0x r10: 0x908321ac r11: 0xa0a20f9c r12: 0x9023dc44 r13: 0x r14: 0x r15: 0x r16: 0x00043538 r17: 0x00043538 r18: 0x00043538 r19: 0x00043538 r20: 0x00043538 r21: 0x00043538 r22: 0x00043538 r23: 0xa2eacd9c r24: 0x0003cc08 r25: 0x0003b658 r26: 0xbff0 r27: 0x0008 r28: 0x00318ac0 r29: 0xa01c3140 r30: 0x00318ac0 r31: 0x901c2ca8 Binary Images Description: 0x1000 -0x38fff org.R-project.R 1.11 /Applications/R.app/Contents/MacOS/R 0x205000 - 0x226fff libreadline.5.0.dylib /Library/Frameworks/R.framework/Resources/lib/libreadline.5.0.dylib 0x1008000 - 0x1195fff libR.dylib /Library/Frameworks/R.framework/Resources/lib/libR.dylib 0x806c - 0x806e9fff libxslt.1.dylib /usr/lib/libxslt.1.dylib 0x8083 - 0x8090efff libxml2.2.dylib /usr/lib/libxml2.2.dylib 0x8ed6 - 0x8ed62fff com.apple.ExceptionHandling 1.2 (???) /System/Library/Frameworks/ExceptionHandling.framework/Versions/A/ExceptionHandling 0x8fe0 - 0x8fe4 dyld/usr/lib/dyld 0x9000 - 0x9014 libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x901c - 0x9026dfff com.apple.CoreFoundation 6.3.7 (299.35) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x902b - 0x90529fff com.apple.CoreServices.CarbonCore 10.3.7 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x90584000 - 0x905f3fff com.apple.framework.IOKit 1.3.6 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x9061 - 0x9069afff com.apple.CoreServices.OSServices 3.0.1 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x9070 - 0x90700fff com.apple.CoreServices 10.3 (???) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x907f - 0x907f9fff com.apple.DiskArbitration 2.0.5 /System/Library/PrivateFrameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x9081 - 0x90810fff com.apple.ApplicationServices 1.0 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x9083 - 0x9089 libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x908c5000 - 0x908d5fff com.apple.vecLib 3.0.3 (vecLib 3.0.3) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x9094 - 0x909b3fff com.apple.DesktopServices 1.2.5 /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x
Re: [Rd] R worked once, now will not open. Works in console, but won't graph. (PR#7953)
Richard, thank you for the report. From the log it seems to be a problem with your preferences. Please delete the file ~/Library/Preferences/org.R- project.R.plist (e.g. type rm ~/Library/Preferences/org.R-project.R.plist in Terminal or simply delete than file using Finder) and let me know if that fixes the problem (actually if it's easy for you to do you could send me the file before you delete it if it turns out to be the problem). In addition you may want to download the latest version of R.app from http://www.rosuda.org/R/nightly/ . Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#7951) DispatchOrEval missing in do_isfinite and
These functions are not generic according to the help page.
The same page says explicitly that is.nan is generic.
Where did you get the (false) idea that they were generic?
On Thu, 16 Jun 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Lars Hansen
> Version: 2.1.0
> OS: SunOS 5.8
> Submission from: (NULL) (207.66.36.189)
>
>
> Hi,
>
> S4 method displacth does not work for the two generic functions
> 'is.finite' and 'is.infinite'. It turns out that the C functions
> 'do_isfinite' and 'do_isinfinite' in src/main/coerce.c are missing a
> call to 'DispatchOrEval' (see do_isnan). Added in the call fixed the
> problem. My functions no look like this:
>
> Form coerce.c:
>
> SEXP do_isfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
> {
>SEXP ans, x, names, dims;
>int i, n;
>
>if (DispatchOrEval(call, op, "is.finite", args, rho, &ans, 1, 1))
>return(ans);
>
>checkArity(op, args);
>...
>
> SEXP do_isinfinite(SEXP call, SEXP op, SEXP args, SEXP rho)
> {
>SEXP ans, x, names, dims;
>double xr, xi;
>int i, n;
>
>if (DispatchOrEval(call, op, "is.infinite", args, rho, &ans, 1, 1))
>return(ans);
>
>checkArity(op, args);
>...
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
