[Phylobase-devl] New phylobase build approach using static libncl (Was: Rcpp and OS X compiliation)

[Peter Cowan]

On Feb 28, 2010, at 9:47 PM, Mark Holder wrote:

> Hi all,
> 
>> On Feb 27, 2010, at 11:55 AM, François Michonneau wrote:
>> 
>>> If I remember correctly, none of the nexus files that are included in
>>> the package work (pkg/inst/nexusfiles). The only file that I can get
>>> to work is the example file that's on the NCL website
>>> (http://hydrodictyon.eeb.uconn.edu/ncl/#readerdata).
>> 
>> There is definitely some weirdness going on.  I tried to debug this a little bit, but the fix and rebuild the whole package cycle to test is pretty tedious.  Are there suggestions for how to shorten it up?  Using R CMD SHLIB on a single file and trying to load that (unsurprisingly) doesn't work.  I attempted briefly to build a standalone NCL program to check the output, but my C++ isn't good enough to make this practical.  Is there such a program out there, with available source for us to study from?
> 
> I'm no good with R.  So I just took the NCLInterface .h and .cpp from phylobase and committed them as an example file in NCL.  That should make it easier (at least for me) to test.
> 
> Those cloned files now live at:
> 	https://ncl.svn.sourceforge.net/svnroot/ncl/branches/v2.1/example/phylobaseinterface
> in the NCL repo.
> 
> 
> I can work with that code and make it more forgiving.  The NEXUS files that are in the phylobase repo are not strict-NEXUS.  But they are *very* common "dialects."  NCL will handle them, but the BASICCMDLINE example program that Brian and Derrick used as a starting point for NCLInterface.cpp is not sophisticated enough to allow NCL to work in non-strict mode.

Great!  One of the goals of phylobase it to be able to interpret a large number of the commonly used nexus-like files, and was the motivation for using NCL.  


> I should be able to fix that aspect of things tomorrow.  When I push those changes to NCL, I'll post to this list so that someone with write permissions to phylobase's svn repo can copy those changes into the phylobase.

I'm happy to do this.

>> The inst/nexusfiles folder contains: co1.nex, MultiLineTrees.nex, treepluscharV01.nex
>> 
>> The first two didn't work, but the last one partially works.  I get a tree that looks like expected, but there is something clearly off with the data portion.
>> 
>> 1. readNexus(file, type=all) returns a phylo4 instead of a phylo4d
>> 2. readNexus(file, type=data) returns the following dataframe regardless of what file it's called on (I tried to do a search on the whole package for "Girth" but didn't find anything).   Even a non-nexus file produces this output.
> 
> 
> The "Girth" dataframe that you are seeing is what you see. If you launch R and type "trees"  Apparently a trees dataset ships with R.
> 
> My guess is that:
> 	1. a phylobase calls fail:
> 	2. not all failures are being detected,
> 	3. A local variable called "trees" in the readNexus function scope is not created,
> 	4. subsequent code refers to "trees", and R eventually maps this name to the trees data set.
> 
> Just a guess.  Surely, R has some way to restrict name scoping to within a function, to prevent this type of cryptic behavior (right?)

I never noticed the trees dataset before.  Dirk pointed out the location of a typo that appears to be the culprit.  But, 1 and 2 are definitely both issues also.

>> Lastly, is there a way to control the output though Rcpp or otherwise, a fair bit of what appears to be stderr gets printed in the R console, it'd be nice to control this.
> 
> The BASICCMDLINE implementation writes lots of status output to the standard error stream.  When I work with it tomorrow, I can make its chattiness controllable by an argument.

That would be wonderful!

If you have time, I'd like to have a more in depth conversation of what NCL is capable and how it is organized.  Wrapping NCL is, in my opinion, one of the key features of phylobase.  But, I also get the feeling that there is more functionality we aren't taking advantage of.  

Perhaps a GSOC student project could come out of it.  Or at the very least I can expand the developers guide section about NCL so we are better able to maintain it in the future.

Peter

> 
> 
> all the best,
> Mark
> 
>