Skip to content

freetype 2.5.2, problem with the survival package, build R 2.15.x with gcc 4.8.x

1 message · Hin-Tak Leung

Original
Hin-Tak Leung
# 
------------------------------
On Fri, Dec 13, 2013 16:29 GMT David Winsemius wrote:

            

      
      
      
    

        
The freetype issues affects both windows and mac users. Unix users have it easier, since R on unices (*excluding* Mac OS X) dynamically
links to the system's shared freetype, so upgrading at the system level would work. R for windows and Mac OS X are statically linked to
a rather out-dated version of freetype.

The survival package issues affects everybody using R more recent than survival package r11513 
Date:   Wed Feb 1 22:47:36 2012 +0000
    Remove "browser()" line from survobrien,
    add coxexact.fit

            

      
      
      
    

        
Your comprehension of the issue seem to be entirely wrong. Between r11513 and r11516, some tuning of internal parmeters were done, so the process of finding the rank of a singular matrix no longer converges (within the time/tolerance implicitly specified). There are warnings issued, but then there are misc warnings before and after (and one gets "desensitised" about them). Also the nature of the problem, which is to test for possibility of interactions - or lacking thereof -

outcome ~ factor A + factor B + factor A x factor B

or just extra terms in "outcome ~ factor A + factor B + ..." as an exploration of auxiliary effects, more often than not extra terms won't make
any difference and the matrix involved just isn't the nicest to manipulate; it is in the nature of that kind of exploratory work.

Professor Therneau replied that it is possible to get the older convergent behaviour by manual tuning of some of the convergence criteria parameters; I have responded that while that is possible, often one is simultaneously exploring many models with many possible auxiliary effects (and lacking thereof), manual tuning for each is neither feasible nor appropriate; and we sort of left it at that.

BTW, I trimmed the vignette and the data down - from a 70MB thing - to a 40k and about 20 lines of R code, and put it under *_trimmed.{Rcode/Rda}.
http://sourceforge.net/projects/outmodedbonsai/files/Manuals%2C%20Overviews%20and%20Slides%20for%20talks/2013SummerCourse/practicals/with-answers/

and with the outcomes (*.Rout.*) from R 3.1.0 (R dev trunk), R 2.15.x, and R 2.15.x with survival r11513.

There are also *_memoryhog.{Rcode,Rda}, for those who want to see what's the memory hog problem with r11515. Obviously there is no Rout files, since I had to kill the R process to stop it hogging my system :-).

As for the gcc 4.8.x issue, I rather think describing r62430 as "tweak needed for gcc 4.8.x" is unfortunate. For those who haven't got
R dev trunk history handy, r62430 put a zero at the end of an array of 16 to make it 17-element long. Without it, as I wrote,
R 2.15.x built that way would segfault at very innocent things like doing a summary() on a data.frame. (r62431 is part of R 3.0.0 RC).

However, if put a zero at the end of an array of 16 to make it 17-element long is a "fix" to a segmentation fault, it must mean that the code has always been wrong, and that it had relied on the C compiler to generously pad with nulls on uninitialized memory, for the code to work as intended beforehand. AFAIK, the Sun studio compiler behaves that way, and so does a few proprietary unix system's C compiler; It is notably not true for gcc (the gcc developers largerly think programmers should write good code where the i's are dotted and t's are crossed, instead of having the compiler protecting them from their own oversights); moreover, on recent redhat fedora systems (where gcc 4.8.x is likely the first to land), uninitialized memories are explicitly filled with random non-nulls to foil malwares which utilises and skips nulls (=no-ops) to jump to the next instruction the malware places in memory. So "tweak needed for gcc 4.8.x" just isn't a good
 description for that change.