[Phylobase-devl] Compilation woes

[Brian O'Meara]

Thanks for looking into this, Steve and Ben. If it is just a matter of  
old files not being rewritten properly, this should be able to be  
taken care of in the Makefile (effectively, make clean first). I'll  
check it out some more.

For my  part, I think keeping the NCL in phylobase makes a lot of  
sense. For casual users, a key point of interest in phylobase seems to  
be the ability to read data from Nexus files, so keeping NCL in it  
will make it more popular. This might translate into getting more  
developers to adopt it. Also, Ben's point about removing the NCL from  
phylobase decreasing the urgency of doing something about it is a good  
one -- knowing how I operate, it's more likely that I'd fix NCL faster  
as part of a development community where NCL failures might hold up  
development than if I were developing it separately. Of course, if NCL  
repair is still too slow even with this encouragement, it'd argue for  
splitting the code.

For getting trees into phylobase from Nexus files, the tree files are  
actually first processed with the NCL code, then strings are passed  
from that to the read.nexustreestring function. This should  
theoretically allow somewhat more robust handling of Nexus tree files  
than just reading them directly through ape-derived functions, but I  
don't remember showing this with example files that will work with NCL  
but not with ape, and so I agree with Steve that ape-based tree  
reading functions could be used instead of NCL without much loss of  
functionality. Another issue is that ape's read.nexus function just  
gets DNA-formatted characters from a Nexus file: the readwithNCL code  
can read DNA, other molecular characters, continuous characters, and  
discrete characters (as factors, with options for dealing with missing  
states). Recoding ape's function to deal with these character types  
might be more of a pain than getting NCL to compile properly on Linux.  
On the other hand, NCL inputs are converted to phylo4 and phylo4d  
objects using those objects' constructors,  so the functions that read  
Nexus files with the NCL will still work in an S4-appropriate way even  
if put into a separate package.

While we're talking about phylobase future development, Marguerite and  
I ran into a few functions that students would have liked to have in  
phylobase while coding: pre- and post-order tree traversal, a function  
to test a node to see whether it's the root, and an accessor to return  
the length of an edge given a node name or number. Overall, the  
students seemed to like phylobase, which is certainly encouraging.

Thanks again,
Brian

On Aug 3, 2008, at 4:53 PM, Ben Bolker wrote:

>   Hmmm.  I didn't have trouble compiling on x86_32, presumably
> that's more likely to be by accident -- that I happen to have
> a clean copy -- than a 32/64 bit difference -- but I'm not going
> to spend a lot of time trying to reproduce the error. (Steve,
> can you make it happen reproducibly?)
>
>  I'd say it's Brian's call what to do about NCL.  I'm a little
> bit worried about taking it out, just because it will
> decrease the urgency of doing anything about it -- but on the
> other hand, it seems more or less on Brian's shoulders to fix it.
> It would be nice if we could come up with a repeatable way of
> making the errors happen -- I know from experience how frustrating
> it is to try to debug something on a remote build server that only
> builds once a day ... (it would be neat if the R-forge guys could
> set up a build-on-demand server analogous to win-builder.r- 
> project.org).
>
> The other question would be how much of our potential user
> base (ha!) is interested in the capabilities that NCL offers
> beyond the ape stuff ...
>
>  Ben
>
>
> Steve Kembel wrote:
>> Hi Brian,
>> I just tried to build phylobase 0.3-1 on my Linux x86_64 box and  
>> got similar errors to R-Forge (warnings about out of scope  
>> declarations and then some fatal errors in the vignettes). I tried  
>> a bunch of different things, and eventually got the package to  
>> build by simply checking out a fresh copy of the code from the  
>> repository. Logs from the successful build are attached. The cruft  
>> that accumulates as the NCL C++ code is compiled multiple times in  
>> a local directory seems to cause mysterious build errors. My guess  
>> is that this is what is happening on R-Forge. I wonder if there's a  
>> way to make sure the package is being built from a clean copy of  
>> the svn code every time on R-Forge?
>> I know that an awful lot of work went into getting the NCL code  
>> working with phylobase, but the ongoing issues with getting  
>> phylobase to compile and install are a bit of a show-stopper for  
>> the package. Could I suggest that we move the NCL-related code into  
>> its own package for now, until we sort out why the package isn't  
>> building on R-Forge? As far as I can tell, the NCL code isn't  
>> actually being used to read trees (we're already using Brian's  
>> modified version of the ape read.nexus R code to read Nexus trees),  
>> the NCL is just being used to read character data from nexus files  
>> in the NexusToPhylo4D function, right? If we split the NCL code off  
>> into its own package, we'd hopefully eliminate the problems with  
>> compiling and installing phylobase. It might also make it easier to  
>> troubleshoot compiling the NCL code. It would however require  
>> writing a new function or modifying ape's read.nexus.data function  
>> if we want to be able to seamlessly read a tree + data into a  
>> phylo4d object from a Nexus file in phylobase.
>> What do you think of this idea?
>> Cheers,
>> Steve
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Phylobase-devl mailing list
>> Phylobase-devl at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl
>
>