Skip to content

R 2.1.1 slated for June 20

25 messages · M. Edward (Ed) Borasky, Uwe Ligges, Peter Dalgaard +5 more

Original
Peter Dalgaard
# 
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...

Apologies for the late announcement, but my department moved this week
and I needed to be sure that my set-up survived the move.

        -pd
Brian Ripley
#
On Fri, 10 Jun 2005, Peter Dalgaard wrote:

            

      
      
      
    

        
Some things which it would be particularly helpful to have tested:

- FreeBSD.  We believe we have a workaround and it has been tested by
   Rainer Hurling, but tests of the actual beta tarball would be helpful.

- AIX.  I am unclear if R currrently builds on AIX.

- Solaris 10.  I believe that various people have now succeeded, but
   it would be good to have positive feedback, especially if anyone has
   the latest Sun compilers (Forte 9?).

- Korean.  We have recently had contributed Korean translations of the
   messages, Windows menus and installer.  It looks like Korean to me, but
   that's as far as it goes.  So please test on Windows and on Unix-alikes,
   the latter in both UTF-8 and EUC-KR if possible.

- 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.)

- Windows:  R for Windows can now be installed in a wide range of Western
   European languages, some Eastern European ones, (Simplified) Chinese,
   Japanese and Korean.  Please test these.  If you know
   Catalan, Czech, Dutch, Hungarian, Norwegian, Polish, (European)
   Portuguese or Slovenian please consider submitting translations for
   the following phrases which will otherwise appear in English:

en.regentries=Registry entries:
en.associate=Associate R with .RData files
en.dcom=Register R path for use by the (D)COM server
en.user=User installation
en.compact=Minimal user installation
en.full=Full installation
en.CJK=Chinese/Japanese/Korean installation
en.custom=Custom installation

  
    

      
      
    

  


  


      

    

    
2 days later

    

      
      

        


  

        

      M. Edward (Ed) Borasky
    

    

      
      #
    

  


  

      
Question: I just downloaded the daily Windows build of "R-devel" and it
claims to be a pre-release of R 2.2.0. So ... is the next release 2.1.1
or 2.2.0? Or is there just not a readily-available Windows build of 2.1.1?

        
Peter Dalgaard wrote:

        

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
M. Edward (Ed) Borasky wrote:

            

      
      
      
    

        
R-devel is the development version for R-2.2.0.
You want to download R-patched (to be R-2.1.1) instead.

Uwe Ligges

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:

            

      
      
      
    

        
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

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
Marc,

Thanks for the confirmation.  Is this using gfortran too?  A date of
20050519 should be after the show-stopper bug was fixed, but I am waiting 
for 4.0.1 to be released (imminent) before doing more tests with gcc4.

Brian

        
On Tue, 14 Jun 2005, Marc Schwartz wrote:

        

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
Prof. Ripley,

If my read of the config.log is correct, it would appear that g77 was
used and not gfortran (which is installed):

...
  C compiler:                gcc  -g -O2
  C++ compiler:              g++  -g -O2
  Fortran compiler:          g77  -g -O2
...


$ g77 --version
GNU Fortran (GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4)) 3.2.3
20030502 (Red Hat Linux 3.2.3-13)


$ gfortran --version
GNU Fortran 95 (GCC 4.0.0 20050519 (Red Hat 4.0.0-8))


Checking 'man gfortran':

Gfortran is not yet a fully conformant Fortran 95 compiler.  It can
generate code for most constructs and expressions, but work remains to
be done.  In particular, there are known deficiencies with ENTRY,
NAMELIST, and sophisticated use of MODULES, POINTERS and DERIVED TYPES.
For those whose Fortran codes conform to either the Fortran 77 standard
or the GNU Fortran 77 language, we recommend to use g77 from GCC 3.4.
We recommend that distributors continue to provide packages of g77-3.4
until we announce that gfortran fully replaces g77. The gfortran
developers welcome any feedback on user experience with gfortran at
<fortran at gcc.gnu.org>.


HTH,

Marc

        
On Tue, 2005-06-14 at 21:12 +0100, Prof Brian Ripley wrote:

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Marc Schwartz <MSchwartz at mn.rr.com> writes:

            

      
      
      
    

        
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.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Marc Schwartz <MSchwartz at mn.rr.com> writes:

            

      
      
      
    

        
Mine was


  C compiler:                gcc  -g -O2
  C++ compiler:              g++  -g -O2
  Fortran compiler:          f95  -g -O2

(and f95 is a link to gfortran)

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Tue, 2005-06-14 at 23:52 +0200, Peter Dalgaard wrote:

            

      
      
      
    

        
Yep. Tom "Spot" Callaway is the FE maintainer for R.

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.

Marc

  
  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Wed, 2005-06-15 at 00:01 +0200, Peter Dalgaard wrote:

            

      
      
      
    

        
Interesting. Did you do anything different on the ./configure line?

$ ls -l  /usr/bin/f95
lrwxrwxrwx  1 root root 8 Jun 13 21:18 /usr/bin/f95 -> gfortran

I just tried it again (having installed some FC updates) and I still get
g77...

Marc

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Jun 14, 2005, at 6:16 PM, Marc Schwartz wrote:

        

            

      
      
      
    

        
g77 is probed before f95, so if you have both, g77 is picked unless  
you set F77 explicitly. The exact probe sequence is:

g77 f77 xlf frt pgf77 fort77 fl32 af77 f90 xlf90 pgf90 epcf90 f95  
fort xlf95 ifc efc pgf95 lf95 gfortran (R 2.1.1 beta)
g77 fort77 f77 xlf frt pgf77 cf77 fl32 af77 f95 fort xlf95 ifort ifc  
efc pgf95 lf95 gfortran ftn g95 f90 xlf90 pgf90 pghpf epcf90 fc (R- 
devel)

I guess Peter simply didn't install g77.

Cheers,
Simon

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
For completeness, I also just tried the R 2.1.1 snapshot from yesterday with
gcc-4.0, g++-4.0 and gfortran-4.0 in an up-to-date Debian unstable chroot --
no issues to report from the build and regression test.

Haven't run that version as I currently do not have a system running
unstable, though.

The new package based on R 2.1.1 beta also built on all autobuilders, with
the exceptions of mips and mipsel which appear to be lacking working blas
libs causing an aborted built on these two.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Tue, 2005-06-14 at 22:42 -0400, Simon Urbanek wrote:

            

      
      
      
    

        
Simon,

Thanks for that. When I installed FC4, I used the option to install
"Everything", which is what I have done with each prior release going
back to RH 8.0. Of course with many things being moved to Extras,
"Everything" is now a shadow of it's former meaning.

It is noted that "Everything" includes RPMS that are not explicitly
listed in other pre-defined groups for installation.

In reviewing the Add/Remove Application GUI, gfortran is listed as an
"Extra Package" in the Development Tools Group.

g77 is not listed in that Group or in the Legacy Development Group, so
it would appear that it is a "silent" part of the "Everything"
installation procedure.

Removing the offending RPM:

rpm -e compat-gcc-32-g77-3.2.3-47.fc4

I now get:

  C compiler:                gcc  -g -O2
  C++ compiler:              g++  -g -O2
  Fortran compiler:          f95  -g -O2


I re-compiled and did note the warning messages that I believe Peter
referred to:

f95   -g -O2 -c blas.f -o blas.o
 In file blas.f:1561

      GO TO IGO,(120,150,180,210)
              1
Warning: Obsolete: Assigned GOTO statement at (1)
 In file blas.f:1567

               ASSIGN 120 TO IGO
                                                                       1
Warning: Obsolete: ASSIGN statement at (1)
 In file blas.f:1579

               ASSIGN 150 TO IGO
                                                                       1
Warning: Obsolete: ASSIGN statement at (1)
 In file blas.f:1592

               ASSIGN 180 TO IGO
                                                                       1
Warning: Obsolete: ASSIGN statement at (1)
 In file blas.f:1603

               ASSIGN 210 TO IGO
                                                                       1
Warning: Obsolete: ASSIGN statement at (1)



make check-all passes with no errors, so no change there.


Regards,

Marc

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
Our preference is F77 compilers over F9x ones, as the lists Simon showed 
reflects - we decided to prefer F95 to F90 in future, though.

My experience is that g77 from gcc-3.4.x is preferable to gfortran.
As I said earlier, once gcc-4.0.1 is released (and so R builds with a 
released version of gcc-4.x.y - 4.0.0 needs worarounds)  I will take a 
another look.  So far, using gcc-3.4.4 is both faster and more accurate 
that gcc-4.0.0.  There are a few instances in which loess gives rather 
different results with gfortran, but they are only visible by diffing
postscript files.

I will look into converting blas.f to F77 (but not for this release).

        
On Tue, 14 Jun 2005, Marc Schwartz wrote:

        

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Marc Schwartz <MSchwartz at mn.rr.com> writes:

            

      
      
      
    

        
I just didn't install g77... (it's listed under "back-compatibility
tools" or something like that).

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Tue, 2005-06-14 at 23:08 -0500, Marc Schwartz wrote:

        
<snip>

            

      
      
      
    

        
Correction:

I noted that under the Legacy Development Group there is just a general
category for "compat-gcc-32", which upon further review appears to
include the above g77 RPM as well as:

compat-gcc-32-c++-3.2.3-47.fc4
compat-gcc-32-3.2.3-47.fc4

My oversight.

Marc

  
  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Wed, 2005-06-15 at 07:51 +0100, Prof Brian Ripley wrote:

            

      
      
      
    

        
<snip>

I have re-installed g77 and re-compiled from scratch with it.

Unless the FC folks have backported gcc-3.4 updates to gcc-3.2, that
update appears to not be imminent, as the FC devel tree (rawhide) is
still at gcc-3.2.

Best regards,

Marc

  
  


  


      

    

    

      
      

        


  

        

      Martyn Plummer
    

    

      
      #
    

  


  

      
On Tue, 2005-06-14 at 17:07 -0500, Marc Schwartz wrote:

            

      
      
      
    

        
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.

            

      
      
      
    

        
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

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Thu, 16 Jun 2005, Martyn Plummer wrote:

        

            

      
      
      
    

        
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.

            

      
      
      
    

        
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.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Martyn Plummer <plummer at iarc.fr> writes:

            

      
      
      
    

        
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).

            

      
      
      
    

        
What is a good way to measure that? For hardcore numerics, it is
certainly much less than 15% on the AMD64:

# RPM:

            

      
      
      
    

        
[1] 8.64 0.15 8.86 0.00 0.00

# My private build
[pd at localhost ~]$ r-patched/BUILD/bin/R -q

            

      
      
      
    

        
[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(10000,t.test(rexp(25),mu=1)$p.value))

I get about 14.1s with the RPM and 11.7s with my build.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Thu, 2005-06-16 at 12:41 +0200, Martyn Plummer wrote:

            

      
      
      
    

        
Martyn,

            

      
      
      
    

        
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.

            

      
      
      
    

        
Yes, this is a sensitive area, but of course Debian has it's own
challenges at the moment, reflected in this article from this week by
Ian Murdock:

http://os.newsforge.com/os/05/06/14/1722241.shtml?tid=2

There is not a single "perfect" Linux distribution and I think that each
user has to make some decisions as to what their overarching
requirements are, which could be functional and philosophical. Based
upon those factors, each can select a distribution that makes sense.

Importantly, there are choices available.

Marc

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Thu, 16 Jun 2005, Marc Schwartz wrote:

        

            

      
      
      
    

        
No work is being done on it.  It remains only as an example of a console 
front-end.

Brian

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
On Thu, 2005-06-16 at 15:23 +0100, Prof Brian Ripley wrote:

            

      
      
      
    

        
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

  
  


  


      

    

    

      
      

        


  

        

      Martyn Plummer
    

    

      
      #
    

  


  

      
On Thu, 2005-06-16 at 12:41 +0100, Prof Brian Ripley wrote:

            

      
      
      
    

        
Mea culpa. 

I have asked Tom Callaway whether this was intended as a bug-fix for R
or a workaround.

            

      
      
      
    

        
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.

            

      
      
      
    

        
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.

            

      
      
      
    

        
-----------------------------------------------------------------------
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