[Phylobase-devl] ncl + phylobase

[Mark Holder]

Hi,
	I'm one of the maintainers of NCL.  I apologize that I have not  
chimed in on some of the NCL issues raised on this list.  I wasn't  
registered on this list until a few minutes ago...

	As the previous threads noted there is a pending Google Summer of  
Code project (through NESCent's GSoC application) to add support for  
metadata to NCL. This would entail adding more parsing code (for nexml  
and for NEXUS' Notes block, where Mesquite stuffs some  info) and  
adding an API so that client code could retrieve the data.  Most of  
the client API won't change much, so I don't expect it to have drastic  
effects on phylobase (of course phylobase will have to be changed if  
it wants to query for this data).

	A couple of other things that you might want to look at if you are  
revisiting the NCL/phylobase interaction:

=============================================================
1. SWIG
=============================================================
I recently revived a SWIG wrapper around NCL.  So as not to disturb  
most of NCL users, I put that code on a different branch. The svn repo  
is:
	https://ncl.svn.sourceforge.net/svnroot/ncl/branches/v2.2
the most recent non-SWIG NCL is on:
	https://ncl.svn.sourceforge.net/svnroot/ncl/branches/v2.1

I realize now that I resorted to some hacks to get the swig interface  
file to play nicely with python, so the generation of a full swig  
interface file is currently a little uglier than it should be.  I've  
only test it on python, but it should not be too much additional work  
to get it to work with R.

I suspect that the phylobase/NCL interaction is tighter than the  
minimal SWIG bindings that are supported on the v2.2 branch, but
you may want to consider adopting the SWIG style if it is easy.  I'm  
afraid that my R is terrible, so I won't be of any help with R- 
specific stuff.

I don't intend to add more features to NCL 2.1.  Hopefully when I'm  
confident that the SWIG stuff does not interfere with a non-swig  
build, then 2.2 will be the main branch of development (for curious  
historical reasons the trunk is pretty dead -- we should just call 2.2  
the trunk, but we don't).

=============================================================
2. hook to get a tree when it is read
=============================================================

I've also recently added the ability to register a callback function  
that gets triggered after NCL reads a tree.

If you return false out of the callback, then NCL throws away the  
tree. This can dramatically reduce memory consumption if you are  
processing a stream of trees (for instance a large collection of trees  
from an MCMC analysis).  Jeet Sukumaran and I are using this feature  
(from the SWIG-enabled python bindings to NCL) in our library,  
dendropy, and it makes a huge difference in performance.

=============================================================
3. non-string trees
=============================================================

NCL does actually construct a simple tree in memory during validation  
of tree strings, it wouldn't be too hard to expose that class.  But it  
is also not very feature rich, so I'm not sure that it would help  
you....



All the best,
Mark







Mark Holder

mtholder at ku.edu
mtholder at gmail.com
http://www.people.ku.edu/~mtholder/

==============================================
Department of Ecology and Evolutionary Biology
University of Kansas
6031 Haworth Hall
1200 Sunnyside Avenue
Lawrence, Kansas 66045

lab phone:  785.864.5789

fax (shared): 785.864.5860
==============================================