You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(12) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Mark H. <mth...@ku...> - 2012-07-27 00:03:09
|
Hi all, RAxML does not use NCL, I'm afraid. It might if NCL had been written in C rather than C++, but that ship has sailed. GARLI does. As does the R package (http://cran.r-project.org/web/packages/phylobase/index.html ). DendroPy used to have a working parse-with-NCL-option that read files much faster. But that is broken (and may never come back). all the best, mark On Jul 26, 2012, at 7:56 PM, Hilmar Lapp wrote: > What I'm peripherally aware of is RAxML, RevBayes (the successor of MrBayes), Phycas. But that's probably incomplete, so I'm cross-posting this to the NCL list. > > -hilmar > > Sent with a tap. > > On Jul 26, 2012, at 8:48 AM, Rutger Vos <rut...@gm...> wrote: > >> I am not 100% sure that the GPL automatically applies to code that's >> generated with the xsd tool (but it probably is). In any case, I >> suppose NCL would be the way forward. Please remind me, which current >> programs would then, theoretically, be able to consume/produce NeXML >> provided they update their NCL? >> >> On Thu, Jul 26, 2012 at 2:36 PM, Hilmar Lapp <hl...@ne...> wrote: >>> I agree with the motivation behind further developing the C++ code, and would add that many phylogenetic analysis programs are written in C or C++ and hence this would be what they need to support NeXML more easily. However, I also think that the current C++ code is a dead end, at least if I understand correctly, for the licensing alone (GPL rather than LGPL), because it prevents uptake by commercial or otherwise closed source tools. I think further developing the NCL code, which was recently re-licensed as BSD, is the better way forward. >>> >>> -hilmar >>> >>> Sent with a tap. >>> >>> On Jul 26, 2012, at 8:24 AM, Rutger Vos <rut...@gm...> wrote: >>> >>>> Hi all, >>>> >>>> following Anurag's excellent work in porting the NeXML source tree to >>>> github (from sourceforge) and re-organizing it into smaller >>>> sub-projects I have now finally got around to point the NeXML website >>>> to this new source (including the static HTML for the site itself, >>>> which I tweaked here and there). >>>> >>>> In going through these changes it became clear there's a couple more >>>> things that would perhaps be good to do: >>>> >>>> * we have always used the link http://nexml.org/manual as a proxy for >>>> our wiki page on sourceforge. Since that's the last thing that ties us >>>> to them, we could safely move that wiki somewhere else (e.g. also to >>>> github) and update the redirect. Not urgent, but would be nice. >>>> >>>> * there is still that cpp attempt as part of the source tree. You know >>>> what would be really great? If that was developed a little bit further >>>> so that its xml bean-like facilities were exposed through swig so that >>>> the scripting languages could, alternatively, build on this for their >>>> nexml i/o. I suspect that might give spectacular performance >>>> improvements. >>>> >>>> * (And then there's of course all the bugfixes and enhancements we >>>> know about in the back of our heads). >>>> >>>> Best wishes, >>>> >>>> Rutger >>>> >>>> -- >>>> Dr. Rutger A. Vos >>>> Bioinformaticist >>>> NCB Naturalis >>>> Visiting address: Office A109, Einsteinweg 2, 2333 CC, Leiden, the Netherlands >>>> Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands >>>> http://rutgervos.blogspot.com >>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> Nexml-discuss mailing list >>>> Nex...@li... >>>> https://lists.sourceforge.net/lists/listinfo/nexml-discuss >> >> >> >> -- >> Dr. Rutger A. Vos >> Bioinformaticist >> NCB Naturalis >> Visiting address: Office A109, Einsteinweg 2, 2333 CC, Leiden, the Netherlands >> Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands >> http://rutgervos.blogspot.com > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Nexml-discuss mailing list > Nex...@li... > https://lists.sourceforge.net/lists/listinfo/nexml-discuss > Mark Holder mth...@ku... http://phylo.bio.ku.edu/mark-holder ============================================== 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 ============================================== |
From: Hilmar L. <hl...@ne...> - 2012-07-26 23:56:45
|
What I'm peripherally aware of is RAxML, RevBayes (the successor of MrBayes), Phycas. But that's probably incomplete, so I'm cross-posting this to the NCL list. -hilmar Sent with a tap. On Jul 26, 2012, at 8:48 AM, Rutger Vos <rut...@gm...> wrote: > I am not 100% sure that the GPL automatically applies to code that's > generated with the xsd tool (but it probably is). In any case, I > suppose NCL would be the way forward. Please remind me, which current > programs would then, theoretically, be able to consume/produce NeXML > provided they update their NCL? > > On Thu, Jul 26, 2012 at 2:36 PM, Hilmar Lapp <hl...@ne...> wrote: >> I agree with the motivation behind further developing the C++ code, and would add that many phylogenetic analysis programs are written in C or C++ and hence this would be what they need to support NeXML more easily. However, I also think that the current C++ code is a dead end, at least if I understand correctly, for the licensing alone (GPL rather than LGPL), because it prevents uptake by commercial or otherwise closed source tools. I think further developing the NCL code, which was recently re-licensed as BSD, is the better way forward. >> >> -hilmar >> >> Sent with a tap. >> >> On Jul 26, 2012, at 8:24 AM, Rutger Vos <rut...@gm...> wrote: >> >>> Hi all, >>> >>> following Anurag's excellent work in porting the NeXML source tree to >>> github (from sourceforge) and re-organizing it into smaller >>> sub-projects I have now finally got around to point the NeXML website >>> to this new source (including the static HTML for the site itself, >>> which I tweaked here and there). >>> >>> In going through these changes it became clear there's a couple more >>> things that would perhaps be good to do: >>> >>> * we have always used the link http://nexml.org/manual as a proxy for >>> our wiki page on sourceforge. Since that's the last thing that ties us >>> to them, we could safely move that wiki somewhere else (e.g. also to >>> github) and update the redirect. Not urgent, but would be nice. >>> >>> * there is still that cpp attempt as part of the source tree. You know >>> what would be really great? If that was developed a little bit further >>> so that its xml bean-like facilities were exposed through swig so that >>> the scripting languages could, alternatively, build on this for their >>> nexml i/o. I suspect that might give spectacular performance >>> improvements. >>> >>> * (And then there's of course all the bugfixes and enhancements we >>> know about in the back of our heads). >>> >>> Best wishes, >>> >>> Rutger >>> >>> -- >>> Dr. Rutger A. Vos >>> Bioinformaticist >>> NCB Naturalis >>> Visiting address: Office A109, Einsteinweg 2, 2333 CC, Leiden, the Netherlands >>> Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands >>> http://rutgervos.blogspot.com >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Nexml-discuss mailing list >>> Nex...@li... >>> https://lists.sourceforge.net/lists/listinfo/nexml-discuss > > > > -- > Dr. Rutger A. Vos > Bioinformaticist > NCB Naturalis > Visiting address: Office A109, Einsteinweg 2, 2333 CC, Leiden, the Netherlands > Mailing address: Postbus 9517, 2300 RA, Leiden, the Netherlands > http://rutgervos.blogspot.com |
From: Hilmar L. <hl...@ne...> - 2012-03-17 20:07:53
|
Sorry for the delay in my following up. I did want to say thanks to everyone, and I'm quite humbled by how quickly and generously Mark and everyone else took up the cause. I understand that the 2.2 and XML branches are still on GPL, but if the GSoC project (if it ends up among the accepted ones) can be based off of the 2.1 branch, that'd be a huge win already. -hilmar Sent with a tap. On Mar 9, 2012, at 2:09 PM, Mark Holder <mth...@ku...> wrote: > Hi all, > I'm happy to report that all of the contributors to NCL v2.1 have emailed either me or the list and expressed their willingness to release NCL under a more permissive open source license. > > Thanks to everyone for chiming in so promptly! > > > I have added the Simplified BSD license to version 2.1 (which can be checked out on the svn trunk or on branch 2.1). Paul and I are listed in the license file as the copyright holders, and all contributors are listed in the Authors file. Please speak up if you do not find that to be satisfactory. > > I have posted versions with the new license (and a few minor bug fixes) as zip and tar.gz files on https://sourceforge.net/projects/ncl/ as version 2.1.18. > > I have not heard from everyone who has contributed to different branches, so I have not modified the license of branches/v2.2 or branches/xml > > > all the best, > > Mark > > On Mar 8, 2012, at 3:23 PM, Mark Holder wrote: > >> Hi Hilmar et al., >> >> *** Paul, Derrick, Brian, Brandon, François, Jeet, David, and Mick: please see below and respond! >> >> >> Paul Lewis is the original author of NCL, so the licencse was his decision. >> >> Why don't we see if we can get the authors to agree to a more permissive >> license? >> >> >> >> If you are a contributor to NCL, please respond to me (or the list) to indicate >> whether your fine with dual licensing NCL under GPL and any one of these >> three open source licenses: >> >> LGPL http://www.opensource.org/licenses/LGPL-3.0 >> >> Simplified BSD http://www.opensource.org/licenses/BSD-2-Clause >> >> MIT http://www.opensource.org/licenses/MIT >> >> I'm fine with any of them. Other suggestions are welcome. >> >> The contributors to the main branch of NCL (v2.1) are: >> Me >> Paul O. Lewis >> Derrick Zwickl >> Brian O'Meara >> Brandon Chisham >> François Michonneau >> Jeet Sukumaran >> >> David Suárez Pascal contributed SWIG bindings which heavily influenced those >> found in branches/v2.2 (that was part of the 2007 GSoC, and I updated his work >> to deal with updates to NCL's API). So he is an author of v2.2 branch. >> >> Mick Elliot contributed some code to the xml branch under the 2010 GSoC. >> >> I've bcc'd all of the contributors. >> >> I suppose that if we do not reach a consensus about another license, but Paul >> agrees to a more permissive license, then I can look into producing a version >> of the code that just uses contributions from those authors who give their >> consent. I would estimate that >98% of the code is from Paul or I. >> >> all the best, >> Mark >> >> >> >> On Mar 8, 2012, at 2:33 PM, Hilmar Lapp wrote: >> >>> Mark et al, >>> >>> I'm very pleased to see your NCL project idea on the Phyloinformatics Summer of Code project ideas list! I think getting NeXML (and as you note other standards) capability in there would be really great. >>> >>> Seeing this is also the kick I've needed to resume a discussion that I was in the process of starting here two years or so ago, and then failed to ever take anywhere. So here's my second attempt, and hopefully I'll be better this time in not just dropping the ball before it even gets going. >>> >>> My understanding is that NCL is currently GPL licensed. While there were probably good reasons for doing this when it started, it also does present a barrier to NCL, and thereby capabilities conveyed through NCL, being adopted by phylogenetic analysis programs written in C/C++ that aren't open-source yet are widely used. The most prominent example that comes to mind here is of course PAUP*. As it stands now, PAUP* can't use NCL unless Dave S open-sources it, for which last time I spoke with him he had no plans of doing so. >>> >>> You could of course take the position that the GPL license for NCL is specifically chosen so that projects and developers who themselves don't contribute open-source back to the community can't take advantage of it, thus ostensibly providing an incentive towards greater adoption of open-source. I'm actually not unsympathetic to such a principled stance, if indeed this is the position you and other NCL developers have had in mind with the choice of license. Though, as we probably all know, the real world is more complex; for example, Dave S AFAIK does contribute to open-source projects (such as Phycas), it's just that PAUP* is closed-source. >>> >>> So I'm curious about two things. One, were the barriers to reuse in closed-source and commercial contexts intended when the GPL license was originally chosen? And two, if not, how feasible would it be to change the license of the NCL code to something more permissive, even if only LGPL? >>> >>> -hilmar >>> -- >>> =========================================================== >>> : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : >>> =========================================================== >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> _______________________________________________ >>> Ncl-devel mailing list >>> Ncl...@li... >>> https://lists.sourceforge.net/lists/listinfo/ncl-devel >> >> Mark Holder >> >> mth...@ku... >> http://phylo.bio.ku.edu/mark-holder >> >> ============================================== >> 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 >> ============================================== >> >> >> >> >> >> >> >> > > Mark Holder > > mth...@ku... > http://phylo.bio.ku.edu/mark-holder > > ============================================== > 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 > ============================================== > > > > > > > > > |
From: Mark H. <mth...@ku...> - 2012-03-09 19:09:19
|
Hi all, I'm happy to report that all of the contributors to NCL v2.1 have emailed either me or the list and expressed their willingness to release NCL under a more permissive open source license. Thanks to everyone for chiming in so promptly! I have added the Simplified BSD license to version 2.1 (which can be checked out on the svn trunk or on branch 2.1). Paul and I are listed in the license file as the copyright holders, and all contributors are listed in the Authors file. Please speak up if you do not find that to be satisfactory. I have posted versions with the new license (and a few minor bug fixes) as zip and tar.gz files on https://sourceforge.net/projects/ncl/ as version 2.1.18. I have not heard from everyone who has contributed to different branches, so I have not modified the license of branches/v2.2 or branches/xml all the best, Mark On Mar 8, 2012, at 3:23 PM, Mark Holder wrote: > Hi Hilmar et al., > > *** Paul, Derrick, Brian, Brandon, François, Jeet, David, and Mick: please see below and respond! > > > Paul Lewis is the original author of NCL, so the licencse was his decision. > > Why don't we see if we can get the authors to agree to a more permissive > license? > > > > If you are a contributor to NCL, please respond to me (or the list) to indicate > whether your fine with dual licensing NCL under GPL and any one of these > three open source licenses: > > LGPL http://www.opensource.org/licenses/LGPL-3.0 > > Simplified BSD http://www.opensource.org/licenses/BSD-2-Clause > > MIT http://www.opensource.org/licenses/MIT > > I'm fine with any of them. Other suggestions are welcome. > > The contributors to the main branch of NCL (v2.1) are: > Me > Paul O. Lewis > Derrick Zwickl > Brian O'Meara > Brandon Chisham > François Michonneau > Jeet Sukumaran > > David Suárez Pascal contributed SWIG bindings which heavily influenced those > found in branches/v2.2 (that was part of the 2007 GSoC, and I updated his work > to deal with updates to NCL's API). So he is an author of v2.2 branch. > > Mick Elliot contributed some code to the xml branch under the 2010 GSoC. > > I've bcc'd all of the contributors. > > I suppose that if we do not reach a consensus about another license, but Paul > agrees to a more permissive license, then I can look into producing a version > of the code that just uses contributions from those authors who give their > consent. I would estimate that >98% of the code is from Paul or I. > > all the best, > Mark > > > > On Mar 8, 2012, at 2:33 PM, Hilmar Lapp wrote: > >> Mark et al, >> >> I'm very pleased to see your NCL project idea on the Phyloinformatics Summer of Code project ideas list! I think getting NeXML (and as you note other standards) capability in there would be really great. >> >> Seeing this is also the kick I've needed to resume a discussion that I was in the process of starting here two years or so ago, and then failed to ever take anywhere. So here's my second attempt, and hopefully I'll be better this time in not just dropping the ball before it even gets going. >> >> My understanding is that NCL is currently GPL licensed. While there were probably good reasons for doing this when it started, it also does present a barrier to NCL, and thereby capabilities conveyed through NCL, being adopted by phylogenetic analysis programs written in C/C++ that aren't open-source yet are widely used. The most prominent example that comes to mind here is of course PAUP*. As it stands now, PAUP* can't use NCL unless Dave S open-sources it, for which last time I spoke with him he had no plans of doing so. >> >> You could of course take the position that the GPL license for NCL is specifically chosen so that projects and developers who themselves don't contribute open-source back to the community can't take advantage of it, thus ostensibly providing an incentive towards greater adoption of open-source. I'm actually not unsympathetic to such a principled stance, if indeed this is the position you and other NCL developers have had in mind with the choice of license. Though, as we probably all know, the real world is more complex; for example, Dave S AFAIK does contribute to open-source projects (such as Phycas), it's just that PAUP* is closed-source. >> >> So I'm curious about two things. One, were the barriers to reuse in closed-source and commercial contexts intended when the GPL license was originally chosen? And two, if not, how feasible would it be to change the license of the NCL code to something more permissive, even if only LGPL? >> >> -hilmar >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : >> =========================================================== >> >> >> >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Ncl-devel mailing list >> Ncl...@li... >> https://lists.sourceforge.net/lists/listinfo/ncl-devel > > Mark Holder > > mth...@ku... > http://phylo.bio.ku.edu/mark-holder > > ============================================== > 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 > ============================================== > > > > > > > > Mark Holder mth...@ku... http://phylo.bio.ku.edu/mark-holder ============================================== 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 ============================================== |
From: François M. <fra...@gm...> - 2012-03-09 15:07:05
|
Hi Mark, Any license that helps spread NCL goodness is OK with me. Cheers, -- François On Thu, Mar 8, 2012 at 22:35, Derrick Zwickl <zw...@ku...> wrote: > > Hi Mark, > > I'm also fine with any of those licenses. I wouldn't want to force you > to hack out the handful of lines that I've added :-). > > Derrick > > On 3/8/12 2:23 PM, Mark Holder wrote: > > Hi Hilmar et al., > > > > *** Paul, Derrick, Brian, Brandon, François, Jeet, David, and Mick: > please see below and respond! > > > > > > Paul Lewis is the original author of NCL, so the licencse was his > decision. > > > > Why don't we see if we can get the authors to agree to a more permissive > > license? > > > > > > > > If you are a contributor to NCL, please respond to me (or the list) to > indicate > > whether your fine with dual licensing NCL under GPL and any one of these > > three open source licenses: > > > > LGPL http://www.opensource.org/licenses/LGPL-3.0 > > > > Simplified BSD http://www.opensource.org/licenses/BSD-2-Clause > > > > MIT http://www.opensource.org/licenses/MIT > > > > I'm fine with any of them. Other suggestions are welcome. > > > > The contributors to the main branch of NCL (v2.1) are: > > Me > > Paul O. Lewis > > Derrick Zwickl > > Brian O'Meara > > Brandon Chisham > > François Michonneau > > Jeet Sukumaran > > > > David Suárez Pascal contributed SWIG bindings which heavily influenced > those > > found in branches/v2.2 (that was part of the 2007 GSoC, and I > updated his work > > to deal with updates to NCL's API). So he is an author of v2.2 > branch. > > > > Mick Elliot contributed some code to the xml branch under the 2010 GSoC. > > > > I've bcc'd all of the contributors. > > > > I suppose that if we do not reach a consensus about another license, but > Paul > > agrees to a more permissive license, then I can look into producing a > version > > of the code that just uses contributions from those authors who give > their > > consent. I would estimate that>98% of the code is from Paul or I. > > > > all the best, > > Mark > > > > > > > > On Mar 8, 2012, at 2:33 PM, Hilmar Lapp wrote: > > > >> Mark et al, > >> > >> I'm very pleased to see your NCL project idea on the Phyloinformatics > Summer of Code project ideas list! I think getting NeXML (and as you note > other standards) capability in there would be really great. > >> > >> Seeing this is also the kick I've needed to resume a discussion that I > was in the process of starting here two years or so ago, and then failed to > ever take anywhere. So here's my second attempt, and hopefully I'll be > better this time in not just dropping the ball before it even gets going. > >> > >> My understanding is that NCL is currently GPL licensed. While there > were probably good reasons for doing this when it started, it also does > present a barrier to NCL, and thereby capabilities conveyed through NCL, > being adopted by phylogenetic analysis programs written in C/C++ that > aren't open-source yet are widely used. The most prominent example that > comes to mind here is of course PAUP*. As it stands now, PAUP* can't use > NCL unless Dave S open-sources it, for which last time I spoke with him he > had no plans of doing so. > >> > >> You could of course take the position that the GPL license for NCL is > specifically chosen so that projects and developers who themselves don't > contribute open-source back to the community can't take advantage of it, > thus ostensibly providing an incentive towards greater adoption of > open-source. I'm actually not unsympathetic to such a principled stance, if > indeed this is the position you and other NCL developers have had in mind > with the choice of license. Though, as we probably all know, the real world > is more complex; for example, Dave S AFAIK does contribute to open-source > projects (such as Phycas), it's just that PAUP* is closed-source. > >> > >> So I'm curious about two things. One, were the barriers to reuse in > closed-source and commercial contexts intended when the GPL license was > originally chosen? And two, if not, how feasible would it be to change the > license of the NCL code to something more permissive, even if only LGPL? > >> > >> -hilmar > >> -- > >> =========================================================== > >> : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > >> =========================================================== > >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Virtualization& Cloud Management Using Capacity Planning > >> Cloud computing makes use of virtualization - but cloud computing > >> also focuses on allowing computing to be delivered as a service. > >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ > >> _______________________________________________ > >> Ncl-devel mailing list > >> Ncl...@li... > >> https://lists.sourceforge.net/lists/listinfo/ncl-devel > > Mark Holder > > > > mth...@ku... > > http://phylo.bio.ku.edu/mark-holder > > > > ============================================== > > 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 > > ============================================== > > > > > > > > > > > > > > > > > > > -- > ============================================== > Department of Ecology and Evolutionary Biology > University of Kansas > 6031 Haworth Hall > 1200 Sunnyside Avenue > Lawrence, Kansas 66045 > > lab phone: 785-864-5789 > ============================================== > > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Ncl-devel mailing list > Ncl...@li... > https://lists.sourceforge.net/lists/listinfo/ncl-devel > |
From: Derrick Z. <zw...@ku...> - 2012-03-09 04:21:12
|
Hi Mark, I'm also fine with any of those licenses. I wouldn't want to force you to hack out the handful of lines that I've added :-). Derrick On 3/8/12 2:23 PM, Mark Holder wrote: > Hi Hilmar et al., > > *** Paul, Derrick, Brian, Brandon, François, Jeet, David, and Mick: please see below and respond! > > > Paul Lewis is the original author of NCL, so the licencse was his decision. > > Why don't we see if we can get the authors to agree to a more permissive > license? > > > > If you are a contributor to NCL, please respond to me (or the list) to indicate > whether your fine with dual licensing NCL under GPL and any one of these > three open source licenses: > > LGPL http://www.opensource.org/licenses/LGPL-3.0 > > Simplified BSD http://www.opensource.org/licenses/BSD-2-Clause > > MIT http://www.opensource.org/licenses/MIT > > I'm fine with any of them. Other suggestions are welcome. > > The contributors to the main branch of NCL (v2.1) are: > Me > Paul O. Lewis > Derrick Zwickl > Brian O'Meara > Brandon Chisham > François Michonneau > Jeet Sukumaran > > David Suárez Pascal contributed SWIG bindings which heavily influenced those > found in branches/v2.2 (that was part of the 2007 GSoC, and I updated his work > to deal with updates to NCL's API). So he is an author of v2.2 branch. > > Mick Elliot contributed some code to the xml branch under the 2010 GSoC. > > I've bcc'd all of the contributors. > > I suppose that if we do not reach a consensus about another license, but Paul > agrees to a more permissive license, then I can look into producing a version > of the code that just uses contributions from those authors who give their > consent. I would estimate that>98% of the code is from Paul or I. > > all the best, > Mark > > > > On Mar 8, 2012, at 2:33 PM, Hilmar Lapp wrote: > >> Mark et al, >> >> I'm very pleased to see your NCL project idea on the Phyloinformatics Summer of Code project ideas list! I think getting NeXML (and as you note other standards) capability in there would be really great. >> >> Seeing this is also the kick I've needed to resume a discussion that I was in the process of starting here two years or so ago, and then failed to ever take anywhere. So here's my second attempt, and hopefully I'll be better this time in not just dropping the ball before it even gets going. >> >> My understanding is that NCL is currently GPL licensed. While there were probably good reasons for doing this when it started, it also does present a barrier to NCL, and thereby capabilities conveyed through NCL, being adopted by phylogenetic analysis programs written in C/C++ that aren't open-source yet are widely used. The most prominent example that comes to mind here is of course PAUP*. As it stands now, PAUP* can't use NCL unless Dave S open-sources it, for which last time I spoke with him he had no plans of doing so. >> >> You could of course take the position that the GPL license for NCL is specifically chosen so that projects and developers who themselves don't contribute open-source back to the community can't take advantage of it, thus ostensibly providing an incentive towards greater adoption of open-source. I'm actually not unsympathetic to such a principled stance, if indeed this is the position you and other NCL developers have had in mind with the choice of license. Though, as we probably all know, the real world is more complex; for example, Dave S AFAIK does contribute to open-source projects (such as Phycas), it's just that PAUP* is closed-source. >> >> So I'm curious about two things. One, were the barriers to reuse in closed-source and commercial contexts intended when the GPL license was originally chosen? And two, if not, how feasible would it be to change the license of the NCL code to something more permissive, even if only LGPL? >> >> -hilmar >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : >> =========================================================== >> >> >> >> >> ------------------------------------------------------------------------------ >> Virtualization& Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Ncl-devel mailing list >> Ncl...@li... >> https://lists.sourceforge.net/lists/listinfo/ncl-devel > Mark Holder > > mth...@ku... > http://phylo.bio.ku.edu/mark-holder > > ============================================== > 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 > ============================================== > > > > > > > > -- ============================================== Department of Ecology and Evolutionary Biology University of Kansas 6031 Haworth Hall 1200 Sunnyside Avenue Lawrence, Kansas 66045 lab phone: 785-864-5789 ============================================== |
From: Paul L. <pau...@uc...> - 2012-03-08 23:54:54
|
Hi Mark, I'm OK with any open source license. Cheers, Paul On Mar 8, 2012, at Mar 8, 2012, 16:23 , Mark Holder wrote: > Hi Hilmar et al., > > *** Paul, Derrick, Brian, Brandon, François, Jeet, David, and Mick: please see below and respond! > > > Paul Lewis is the original author of NCL, so the licencse was his decision. > > Why don't we see if we can get the authors to agree to a more permissive > license? > > > > If you are a contributor to NCL, please respond to me (or the list) to indicate > whether your fine with dual licensing NCL under GPL and any one of these > three open source licenses: > > LGPL http://www.opensource.org/licenses/LGPL-3.0 > > Simplified BSD http://www.opensource.org/licenses/BSD-2-Clause > > MIT http://www.opensource.org/licenses/MIT > > I'm fine with any of them. Other suggestions are welcome. > > The contributors to the main branch of NCL (v2.1) are: > Me > Paul O. Lewis > Derrick Zwickl > Brian O'Meara > Brandon Chisham > François Michonneau > Jeet Sukumaran > > David Suárez Pascal contributed SWIG bindings which heavily influenced those > found in branches/v2.2 (that was part of the 2007 GSoC, and I updated his work > to deal with updates to NCL's API). So he is an author of v2.2 branch. > > Mick Elliot contributed some code to the xml branch under the 2010 GSoC. > > I've bcc'd all of the contributors. > > I suppose that if we do not reach a consensus about another license, but Paul > agrees to a more permissive license, then I can look into producing a version > of the code that just uses contributions from those authors who give their > consent. I would estimate that >98% of the code is from Paul or I. > > all the best, > Mark > > > > On Mar 8, 2012, at 2:33 PM, Hilmar Lapp wrote: > >> Mark et al, >> >> I'm very pleased to see your NCL project idea on the Phyloinformatics Summer of Code project ideas list! I think getting NeXML (and as you note other standards) capability in there would be really great. >> >> Seeing this is also the kick I've needed to resume a discussion that I was in the process of starting here two years or so ago, and then failed to ever take anywhere. So here's my second attempt, and hopefully I'll be better this time in not just dropping the ball before it even gets going. >> >> My understanding is that NCL is currently GPL licensed. While there were probably good reasons for doing this when it started, it also does present a barrier to NCL, and thereby capabilities conveyed through NCL, being adopted by phylogenetic analysis programs written in C/C++ that aren't open-source yet are widely used. The most prominent example that comes to mind here is of course PAUP*. As it stands now, PAUP* can't use NCL unless Dave S open-sources it, for which last time I spoke with him he had no plans of doing so. >> >> You could of course take the position that the GPL license for NCL is specifically chosen so that projects and developers who themselves don't contribute open-source back to the community can't take advantage of it, thus ostensibly providing an incentive towards greater adoption of open-source. I'm actually not unsympathetic to such a principled stance, if indeed this is the position you and other NCL developers have had in mind with the choice of license. Though, as we probably all know, the real world is more complex; for example, Dave S AFAIK does contribute to open-source projects (such as Phycas), it's just that PAUP* is closed-source. >> >> So I'm curious about two things. One, were the barriers to reuse in closed-source and commercial contexts intended when the GPL license was originally chosen? And two, if not, how feasible would it be to change the license of the NCL code to something more permissive, even if only LGPL? >> >> -hilmar >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : >> =========================================================== >> >> >> >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Ncl-devel mailing list >> Ncl...@li... >> https://lists.sourceforge.net/lists/listinfo/ncl-devel > > Mark Holder > > mth...@ku... > http://phylo.bio.ku.edu/mark-holder > > ============================================== > 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 > ============================================== > > > > > > > > > -- Paul O. Lewis, Ph.D. Associate Professor Department of Ecology & Evolutionary Biology The University of Connecticut 75 North Eagleville Road, Unit 3043 Storrs, CT 06269-3043 Tel: +01 860 486-2069 Fax: +01 860 486-6364 EEB Dept: http://www.eeb.uconn.edu/ Home Page: http://www.eeb.uconn.edu/people/plewis/ |
From: Brian O'M. <bo...@ut...> - 2012-03-08 21:51:50
|
I'm fine with any of the licensing schemes, plus I like the idea of weighting votes by amount of contribution (in which case, my opinion counts for little). I like the idea of compelling open source use in general, but phylogenetics is so small and yet needs so much work that allowing as much reuse as possible makes sense to me. Brian _______________________________________ Brian O'Meara Assistant Professor Dept. of Ecology & Evolutionary Biology U. of Tennessee, Knoxville http://www.brianomeara.info Students wanted: Applications due Dec. 15, annually Postdoc collaborators wanted: Check NIMBioS' website Calendar: http://www.brianomeara.info/calendars/omeara On Thu, Mar 8, 2012 at 4:23 PM, Mark Holder <mth...@ku...> wrote: > Hi Hilmar et al., > > *** Paul, Derrick, Brian, Brandon, François, Jeet, David, and Mick: please > see below and respond! > > > Paul Lewis is the original author of NCL, so the licencse was his > decision. > > Why don't we see if we can get the authors to agree to a more permissive > license? > > > > If you are a contributor to NCL, please respond to me (or the list) to > indicate > whether your fine with dual licensing NCL under GPL and any one of these > three open source licenses: > > LGPL http://www.opensource.org/licenses/LGPL-3.0 > > Simplified BSD http://www.opensource.org/licenses/BSD-2-Clause > > MIT http://www.opensource.org/licenses/MIT > > I'm fine with any of them. Other suggestions are welcome. > > The contributors to the main branch of NCL (v2.1) are: > Me > Paul O. Lewis > Derrick Zwickl > Brian O'Meara > Brandon Chisham > François Michonneau > Jeet Sukumaran > > David Suárez Pascal contributed SWIG bindings which heavily influenced > those > found in branches/v2.2 (that was part of the 2007 GSoC, and I updated > his work > to deal with updates to NCL's API). So he is an author of v2.2 branch. > > Mick Elliot contributed some code to the xml branch under the 2010 GSoC. > > I've bcc'd all of the contributors. > > I suppose that if we do not reach a consensus about another license, but > Paul > agrees to a more permissive license, then I can look into producing a > version > of the code that just uses contributions from those authors who give their > consent. I would estimate that >98% of the code is from Paul or I. > > all the best, > Mark > > > > On Mar 8, 2012, at 2:33 PM, Hilmar Lapp wrote: > > > Mark et al, > > > > I'm very pleased to see your NCL project idea on the Phyloinformatics > Summer of Code project ideas list! I think getting NeXML (and as you note > other standards) capability in there would be really great. > > > > Seeing this is also the kick I've needed to resume a discussion that I > was in the process of starting here two years or so ago, and then failed to > ever take anywhere. So here's my second attempt, and hopefully I'll be > better this time in not just dropping the ball before it even gets going. > > > > My understanding is that NCL is currently GPL licensed. While there were > probably good reasons for doing this when it started, it also does present > a barrier to NCL, and thereby capabilities conveyed through NCL, being > adopted by phylogenetic analysis programs written in C/C++ that aren't > open-source yet are widely used. The most prominent example that comes to > mind here is of course PAUP*. As it stands now, PAUP* can't use NCL unless > Dave S open-sources it, for which last time I spoke with him he had no > plans of doing so. > > > > You could of course take the position that the GPL license for NCL is > specifically chosen so that projects and developers who themselves don't > contribute open-source back to the community can't take advantage of it, > thus ostensibly providing an incentive towards greater adoption of > open-source. I'm actually not unsympathetic to such a principled stance, if > indeed this is the position you and other NCL developers have had in mind > with the choice of license. Though, as we probably all know, the real world > is more complex; for example, Dave S AFAIK does contribute to open-source > projects (such as Phycas), it's just that PAUP* is closed-source. > > > > So I'm curious about two things. One, were the barriers to reuse in > closed-source and commercial contexts intended when the GPL license was > originally chosen? And two, if not, how feasible would it be to change the > license of the NCL code to something more permissive, even if only LGPL? > > > > -hilmar > > -- > > =========================================================== > > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > > =========================================================== > > > > > > > > > > > ------------------------------------------------------------------------------ > > Virtualization & Cloud Management Using Capacity Planning > > Cloud computing makes use of virtualization - but cloud computing > > also focuses on allowing computing to be delivered as a service. > > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > > _______________________________________________ > > Ncl-devel mailing list > > Ncl...@li... > > https://lists.sourceforge.net/lists/listinfo/ncl-devel > > Mark Holder > > mth...@ku... > http://phylo.bio.ku.edu/mark-holder > > ============================================== > 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 > ============================================== > > > > > > > > > > |
From: Mark H. <mth...@ku...> - 2012-03-08 21:39:16
|
Hi Hilmar et al., *** Paul, Derrick, Brian, Brandon, François, Jeet, David, and Mick: please see below and respond! Paul Lewis is the original author of NCL, so the licencse was his decision. Why don't we see if we can get the authors to agree to a more permissive license? If you are a contributor to NCL, please respond to me (or the list) to indicate whether your fine with dual licensing NCL under GPL and any one of these three open source licenses: LGPL http://www.opensource.org/licenses/LGPL-3.0 Simplified BSD http://www.opensource.org/licenses/BSD-2-Clause MIT http://www.opensource.org/licenses/MIT I'm fine with any of them. Other suggestions are welcome. The contributors to the main branch of NCL (v2.1) are: Me Paul O. Lewis Derrick Zwickl Brian O'Meara Brandon Chisham François Michonneau Jeet Sukumaran David Suárez Pascal contributed SWIG bindings which heavily influenced those found in branches/v2.2 (that was part of the 2007 GSoC, and I updated his work to deal with updates to NCL's API). So he is an author of v2.2 branch. Mick Elliot contributed some code to the xml branch under the 2010 GSoC. I've bcc'd all of the contributors. I suppose that if we do not reach a consensus about another license, but Paul agrees to a more permissive license, then I can look into producing a version of the code that just uses contributions from those authors who give their consent. I would estimate that >98% of the code is from Paul or I. all the best, Mark On Mar 8, 2012, at 2:33 PM, Hilmar Lapp wrote: > Mark et al, > > I'm very pleased to see your NCL project idea on the Phyloinformatics Summer of Code project ideas list! I think getting NeXML (and as you note other standards) capability in there would be really great. > > Seeing this is also the kick I've needed to resume a discussion that I was in the process of starting here two years or so ago, and then failed to ever take anywhere. So here's my second attempt, and hopefully I'll be better this time in not just dropping the ball before it even gets going. > > My understanding is that NCL is currently GPL licensed. While there were probably good reasons for doing this when it started, it also does present a barrier to NCL, and thereby capabilities conveyed through NCL, being adopted by phylogenetic analysis programs written in C/C++ that aren't open-source yet are widely used. The most prominent example that comes to mind here is of course PAUP*. As it stands now, PAUP* can't use NCL unless Dave S open-sources it, for which last time I spoke with him he had no plans of doing so. > > You could of course take the position that the GPL license for NCL is specifically chosen so that projects and developers who themselves don't contribute open-source back to the community can't take advantage of it, thus ostensibly providing an incentive towards greater adoption of open-source. I'm actually not unsympathetic to such a principled stance, if indeed this is the position you and other NCL developers have had in mind with the choice of license. Though, as we probably all know, the real world is more complex; for example, Dave S AFAIK does contribute to open-source projects (such as Phycas), it's just that PAUP* is closed-source. > > So I'm curious about two things. One, were the barriers to reuse in closed-source and commercial contexts intended when the GPL license was originally chosen? And two, if not, how feasible would it be to change the license of the NCL code to something more permissive, even if only LGPL? > > -hilmar > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Ncl-devel mailing list > Ncl...@li... > https://lists.sourceforge.net/lists/listinfo/ncl-devel Mark Holder mth...@ku... http://phylo.bio.ku.edu/mark-holder ============================================== 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 ============================================== |
From: Hilmar L. <hl...@ne...> - 2012-03-08 20:34:27
|
Mark et al, I'm very pleased to see your NCL project idea on the Phyloinformatics Summer of Code project ideas list! I think getting NeXML (and as you note other standards) capability in there would be really great. Seeing this is also the kick I've needed to resume a discussion that I was in the process of starting here two years or so ago, and then failed to ever take anywhere. So here's my second attempt, and hopefully I'll be better this time in not just dropping the ball before it even gets going. My understanding is that NCL is currently GPL licensed. While there were probably good reasons for doing this when it started, it also does present a barrier to NCL, and thereby capabilities conveyed through NCL, being adopted by phylogenetic analysis programs written in C/C++ that aren't open-source yet are widely used. The most prominent example that comes to mind here is of course PAUP*. As it stands now, PAUP* can't use NCL unless Dave S open-sources it, for which last time I spoke with him he had no plans of doing so. You could of course take the position that the GPL license for NCL is specifically chosen so that projects and developers who themselves don't contribute open-source back to the community can't take advantage of it, thus ostensibly providing an incentive towards greater adoption of open-source. I'm actually not unsympathetic to such a principled stance, if indeed this is the position you and other NCL developers have had in mind with the choice of license. Though, as we probably all know, the real world is more complex; for example, Dave S AFAIK does contribute to open-source projects (such as Phycas), it's just that PAUP* is closed-source. So I'm curious about two things. One, were the barriers to reuse in closed-source and commercial contexts intended when the GPL license was originally chosen? And two, if not, how feasible would it be to change the license of the NCL code to something more permissive, even if only LGPL? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Mark H. <mth...@gm...> - 2010-09-30 16:11:56
|
Hi Rutger, As far as I know, the following programs use NCL (though not all use the version that is in Sourceforge - several bundle an old version): - Phycas, - Garli (as DZ mentioned), - TreeView (very old version), - MrBayes4 was going to use - I'm not sure where they stand, - phylobase (R package), - dendropy is not NCL dependent, but if you have NCL and a python adaptor installed then it can use NCL to read tree files much faster than the native python impl. - I have a few NCL-dependent webservices hosted at http://phylo.bio.ku.edu:5000 all the best, Mark On Sep 30, 2010, at 8:35 AM, Rutger Vos wrote: > Hi, > > does anyone know which programs use NCL? In the NeXML manuscript I'd > like to mention that NeXML support in NCL would be a good thing > because a number of programs might take advantage of this - but I > don't know which ones. > > Thanks! > > Rutger > > -- > Dr. Rutger A. Vos > School of Biological Sciences > Philip Lyle Building, Level 4 > University of Reading > Reading > RG6 6BX > United Kingdom > Tel: +44 (0) 118 378 7535 > http://www.nexml.org > http://rutgervos.blogspot.com > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Ncl-devel mailing list > Ncl...@li... > https://lists.sourceforge.net/lists/listinfo/ncl-devel |
From: Michael E. <mi...@sf...> - 2010-09-30 15:56:19
|
One to add to your list if you like is "mixtree", which is described in an article currently in review at Systematic Biology (though since it's in review and not published you might want to leave it out - up to you!) The pdf is at www.sfu.ca/~micke Elliot MG and Mooers AO (2010) Reconstructing ancestral states of continuous characters evolving on phylogenetic trees without assuming neutrality or gradualism. Mick ----- Original Message ----- From: "Rutger Vos" <rut...@gm...> To: "ncl-devel" <ncl...@li...> Sent: Thursday, September 30, 2010 6:35:01 AM Subject: [Ncl-devel] which programs use NCL? Hi, does anyone know which programs use NCL? In the NeXML manuscript I'd like to mention that NeXML support in NCL would be a good thing because a number of programs might take advantage of this - but I don't know which ones. Thanks! Rutger -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Ncl-devel mailing list Ncl...@li... https://lists.sourceforge.net/lists/listinfo/ncl-devel |
From: Derrick Z. <zw...@ku...> - 2010-09-30 15:51:46
|
Rutger, GARLI is an obligate user of it. Cheers, Derrick On 9/30/10 8:35 AM, Rutger Vos wrote: > Hi, > > does anyone know which programs use NCL? In the NeXML manuscript I'd > like to mention that NeXML support in NCL would be a good thing > because a number of programs might take advantage of this - but I > don't know which ones. > > Thanks! > > Rutger > |
From: Rutger V. <rut...@gm...> - 2010-09-30 13:35:09
|
Hi, does anyone know which programs use NCL? In the NeXML manuscript I'd like to mention that NeXML support in NCL would be a good thing because a number of programs might take advantage of this - but I don't know which ones. Thanks! Rutger -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com |
From: Michael E. <mi...@sf...> - 2010-05-27 14:57:00
|
It just occurred to me this morning that we don't need to modify NCL's internal representation of trees as newick strings at all. We can simply have each tree own a list of metadata structs whose length is equal to the number of nodes in the tree. This metadata is indexed by the preorder traversal order of the tree, so that item zero is the root node, item 1 is the root node's left child, etc. We don't need to actually store these indices in the tree because, if the metadata is accessed by iterator, the iterator would visit nodes in the same order in which the metadata is stored. We just need to have the iterator maintain a counter which is incremented each time a new node is visited. This should be of relief to Mark since it definitely wouldn't screw up existing code, it would be a pure independent addition of new and separate functionality. Mick ----- Original Message ----- From: "Mark Holder" <mth...@gm...> To: "ncl-devel" <ncl...@li...> Sent: Wednesday, May 26, 2010 7:27:09 PM GMT -08:00 US/Canada Pacific Subject: Re: [Ncl-devel] annotation API for NCL Hi, On May 25, 2010, at 11:18 PM, Jeet Sukumaran wrote: > ...Instead, I think that if client code wants > to access annotations on tree components, it would be perfectly fair to > expect them to ask for a NCL Tree object and deal or otherwise harvest > info from that. That way, edge and node annotations can be managed using > the the same "porcelain" as for any other "first class" NCL objects. > On May 26, 2010, at 5:37 PM, Michael Elliot wrote: > So the tree storage would be a set of modified newick strings. But the newick string would be used to generate a true tree data structure... I agree that storing the tree is some compact form (presumably a newick string) but generating a traversable tree (with node and edge structures) on-the-fly would work well and be non-disruptive. NCL has never had a good metadata system before, so we can impose some constraints on that part of the API to make our life easier and not worry about breaking client code. It would certainly simplify the tree-metadata API if the contract were strict. Such as: 1. NCL stores the annotations for the nodes and edges in some way (we could use unique keys as Mick suggests, but I have some other thoughts below). The details of the storage would be none of the client's business; 2. Client code can still request the newick string without any funky markup. This is how a lot of client code interacts with NCL's trees block, so we can' change this. 3. If the client wants the richer metadata, then they will have to request that the tree be instantiated as a simple traversable tree. This can already be done using the NxsSimpleTree class. We can expand to fit our needs as it has never been a core "promise" of the NCL interface. We would just need to add a field to NxsSimpleNode and NxsSimpleEdge where the library can attach a collection of annotations. I don't really want to make the core tree storage fatter (or "more prosperous" if those of you prefer) than it is now. I definitely use NCL to crunch huge tree files. Typically that would be done in context in which I would not need or want lots of metadata. It would be good not to pay a heavy price in terms of performance (not that any of the proposed changes would be too expensive, but I just wanted to reiterate that constraint). Clearly adding the flexibility to deal with metadata may have some small performance cost, but we should be wary about things that will make it painful to parse files with thousands of trees (each of which has thousands of leaves). On the topic of storing the association between the metadata and the edge and node: After parsing, the tree NCL stores it as a newick string with numbers instead of names so that the client doesn't have to worry about parsing funky taxon names (and the fact that 'a b' and a_b are the same taxon, plus the translate table could mean that 'biae' is also mapped to that taxon, plus the taxa have implicit numbering in nexus so a number is fine...). We'd need to be able to produce the numbers-only newick form (to avoid breaking client code). So, if we do want to decorate the tree with unique codes (delimited by # and $ for example), then we'd have to strip those codes out before returning them to the client. That is not too big deal, obviously. We could also add a new method for getting the newick string with the codes in there (for client who want to deal with that). I don't have a strenuous objection to that approach. However, I slightly prefer imposing the contract that you only get Edge and Node metadata if you ask for the full tree instantiation. This gives the flexibility to play around with how we store the association internally, as long as we can decorate the tree that is generated on-the-fly. Given that the internal structure is a "normalized" newick string, I'm tempted to say that we don't need an id system. Consider the newick string: (1,(3,5),(4,2:3.4)); The leaves are easily identified (they are numbers that do not follow : and they are constrained to be 1 + the index in the NxsTaxaBlock, so there will be know clashes). If we have node-annotation storage and edge-annotation storage separate, then the taxon id can be used as the "key" to find the terminal edge annotations. Annotations for internal nodes (and edges) can then be accomplished by a number of systems. Perhaps the easiest is to recognize that every internal node has a closing ')' character associated with it. The offset of that closing parentheses from the start of the string, is thus a unique identifier for the node. If we were not "exporting" these ids (and making client code learn the system), then the fact that the system is a bit cryptic (OK, more than a *bit* cryptic) would not cause headaches for clients. Just a thought. I don't have serious objections to coming up with a clear system of tagging edges and nodes with labels, but we may not need it. all the best, Mark [snip] ------------------------------------------------------------------------------ _______________________________________________ Ncl-devel mailing list Ncl...@li... https://lists.sourceforge.net/lists/listinfo/ncl-devel |
From: Michael E. <mi...@sf...> - 2010-05-27 03:09:51
|
OK, I understand what you're saying here: NO CHANGES TO THE EXISTING INTERFACE. Any new tree representations should be provided by new functions, and the existing functions should give identical output after any of my code modifications, and we should use the existing unique ids for attaching data to nodes/edges as much as possible. The only thing I'm not sure about is the latter point - consider your example: (1,(3,5),(4,2:3.4)); Internally we will need at least to store: (1,(3,5)6,(4,2:3.4)7)8; So perhaps some mechanism to remember which nodes are labelled with TAXA ids and which are labelled otherwise is in order. Like (internally) (1,(3,5)!6,(4,2:3.4)!7)!8; or whatnot. What the '!' is doesn't really matter as long is it isn't input by client code in the initial tree file. It could be a non-writing ascii code (like zero). It could be as simple as a space (since these are already removed from the representation of NxsSimpleTree during reading, so are guaranteed to be absent from the internal newick representation, right? If spaces are guaranteed to be absent from NxsSimpleTree taxon labels then we are free to use them as custom tokens in the library) input tree in nexus or other file = (1, (3, 5), (4,2 : 3.4) ); (or whatever) input tree after loading into ncl using current code: (1,(3,5),(4,2:3.4)); (spaces are ignored) input tree after my code has applied ids to any "unlabelled" nodes: (1,(3,5) 6,(4,2:3.4) 7) 8; [space used as delimiter for non-taxa labels] each tree loaded from a non-nexml source has a null node and edge hash table or equivalent std::map<unsigned int, SomeNodeMetadataStruct> * nodeData = 0; std::map<unsigned int, SomeEdgeMetadataStruct> * edgeData = 0; if the tree is loaded from a nexml source the hash tables are instantiated nodeData = new SomeNodeMetadataStruct; edgeData = new SomeEdgeMetadataStruct; So the cost of these modifications is a slightly longer stored newick string, and two null pointers per tree (when loaded from a non-nexml source) or a couple of int/string hash tables (when loaded from a nexml source) Mick ----- Original Message ----- From: "Mark Holder" <mth...@gm...> To: "ncl-devel" <ncl...@li...> Sent: Wednesday, May 26, 2010 7:27:09 PM GMT -08:00 US/Canada Pacific Subject: Re: [Ncl-devel] annotation API for NCL Hi, On May 25, 2010, at 11:18 PM, Jeet Sukumaran wrote: > ...Instead, I think that if client code wants > to access annotations on tree components, it would be perfectly fair to > expect them to ask for a NCL Tree object and deal or otherwise harvest > info from that. That way, edge and node annotations can be managed using > the the same "porcelain" as for any other "first class" NCL objects. > On May 26, 2010, at 5:37 PM, Michael Elliot wrote: > So the tree storage would be a set of modified newick strings. But the newick string would be used to generate a true tree data structure... I agree that storing the tree is some compact form (presumably a newick string) but generating a traversable tree (with node and edge structures) on-the-fly would work well and be non-disruptive. NCL has never had a good metadata system before, so we can impose some constraints on that part of the API to make our life easier and not worry about breaking client code. It would certainly simplify the tree-metadata API if the contract were strict. Such as: 1. NCL stores the annotations for the nodes and edges in some way (we could use unique keys as Mick suggests, but I have some other thoughts below). The details of the storage would be none of the client's business; 2. Client code can still request the newick string without any funky markup. This is how a lot of client code interacts with NCL's trees block, so we can' change this. 3. If the client wants the richer metadata, then they will have to request that the tree be instantiated as a simple traversable tree. This can already be done using the NxsSimpleTree class. We can expand to fit our needs as it has never been a core "promise" of the NCL interface. We would just need to add a field to NxsSimpleNode and NxsSimpleEdge where the library can attach a collection of annotations. I don't really want to make the core tree storage fatter (or "more prosperous" if those of you prefer) than it is now. I definitely use NCL to crunch huge tree files. Typically that would be done in context in which I would not need or want lots of metadata. It would be good not to pay a heavy price in terms of performance (not that any of the proposed changes would be too expensive, but I just wanted to reiterate that constraint). Clearly adding the flexibility to deal with metadata may have some small performance cost, but we should be wary about things that will make it painful to parse files with thousands of trees (each of which has thousands of leaves). On the topic of storing the association between the metadata and the edge and node: After parsing, the tree NCL stores it as a newick string with numbers instead of names so that the client doesn't have to worry about parsing funky taxon names (and the fact that 'a b' and a_b are the same taxon, plus the translate table could mean that 'biae' is also mapped to that taxon, plus the taxa have implicit numbering in nexus so a number is fine...). We'd need to be able to produce the numbers-only newick form (to avoid breaking client code). So, if we do want to decorate the tree with unique codes (delimited by # and $ for example), then we'd have to strip those codes out before returning them to the client. That is not too big deal, obviously. We could also add a new method for getting the newick string with the codes in there (for client who want to deal with that). I don't have a strenuous objection to that approach. However, I slightly prefer imposing the contract that you only get Edge and Node metadata if you ask for the full tree instantiation. This gives the flexibility to play around with how we store the association internally, as long as we can decorate the tree that is generated on-the-fly. Given that the internal structure is a "normalized" newick string, I'm tempted to say that we don't need an id system. Consider the newick string: (1,(3,5),(4,2:3.4)); The leaves are easily identified (they are numbers that do not follow : and they are constrained to be 1 + the index in the NxsTaxaBlock, so there will be know clashes). If we have node-annotation storage and edge-annotation storage separate, then the taxon id can be used as the "key" to find the terminal edge annotations. Annotations for internal nodes (and edges) can then be accomplished by a number of systems. Perhaps the easiest is to recognize that every internal node has a closing ')' character associated with it. The offset of that closing parentheses from the start of the string, is thus a unique identifier for the node. If we were not "exporting" these ids (and making client code learn the system), then the fact that the system is a bit cryptic (OK, more than a *bit* cryptic) would not cause headaches for clients. Just a thought. I don't have serious objections to coming up with a clear system of tagging edges and nodes with labels, but we may not need it. all the best, Mark [snip] ------------------------------------------------------------------------------ _______________________________________________ Ncl-devel mailing list Ncl...@li... https://lists.sourceforge.net/lists/listinfo/ncl-devel |
From: Mark H. <mth...@gm...> - 2010-05-27 02:27:52
|
Hi, On May 25, 2010, at 11:18 PM, Jeet Sukumaran wrote: > ...Instead, I think that if client code wants > to access annotations on tree components, it would be perfectly fair to > expect them to ask for a NCL Tree object and deal or otherwise harvest > info from that. That way, edge and node annotations can be managed using > the the same "porcelain" as for any other "first class" NCL objects. > On May 26, 2010, at 5:37 PM, Michael Elliot wrote: > So the tree storage would be a set of modified newick strings. But the newick string would be used to generate a true tree data structure... I agree that storing the tree is some compact form (presumably a newick string) but generating a traversable tree (with node and edge structures) on-the-fly would work well and be non-disruptive. NCL has never had a good metadata system before, so we can impose some constraints on that part of the API to make our life easier and not worry about breaking client code. It would certainly simplify the tree-metadata API if the contract were strict. Such as: 1. NCL stores the annotations for the nodes and edges in some way (we could use unique keys as Mick suggests, but I have some other thoughts below). The details of the storage would be none of the client's business; 2. Client code can still request the newick string without any funky markup. This is how a lot of client code interacts with NCL's trees block, so we can' change this. 3. If the client wants the richer metadata, then they will have to request that the tree be instantiated as a simple traversable tree. This can already be done using the NxsSimpleTree class. We can expand to fit our needs as it has never been a core "promise" of the NCL interface. We would just need to add a field to NxsSimpleNode and NxsSimpleEdge where the library can attach a collection of annotations. I don't really want to make the core tree storage fatter (or "more prosperous" if those of you prefer) than it is now. I definitely use NCL to crunch huge tree files. Typically that would be done in context in which I would not need or want lots of metadata. It would be good not to pay a heavy price in terms of performance (not that any of the proposed changes would be too expensive, but I just wanted to reiterate that constraint). Clearly adding the flexibility to deal with metadata may have some small performance cost, but we should be wary about things that will make it painful to parse files with thousands of trees (each of which has thousands of leaves). On the topic of storing the association between the metadata and the edge and node: After parsing, the tree NCL stores it as a newick string with numbers instead of names so that the client doesn't have to worry about parsing funky taxon names (and the fact that 'a b' and a_b are the same taxon, plus the translate table could mean that 'biae' is also mapped to that taxon, plus the taxa have implicit numbering in nexus so a number is fine...). We'd need to be able to produce the numbers-only newick form (to avoid breaking client code). So, if we do want to decorate the tree with unique codes (delimited by # and $ for example), then we'd have to strip those codes out before returning them to the client. That is not too big deal, obviously. We could also add a new method for getting the newick string with the codes in there (for client who want to deal with that). I don't have a strenuous objection to that approach. However, I slightly prefer imposing the contract that you only get Edge and Node metadata if you ask for the full tree instantiation. This gives the flexibility to play around with how we store the association internally, as long as we can decorate the tree that is generated on-the-fly. Given that the internal structure is a "normalized" newick string, I'm tempted to say that we don't need an id system. Consider the newick string: (1,(3,5),(4,2:3.4)); The leaves are easily identified (they are numbers that do not follow : and they are constrained to be 1 + the index in the NxsTaxaBlock, so there will be know clashes). If we have node-annotation storage and edge-annotation storage separate, then the taxon id can be used as the "key" to find the terminal edge annotations. Annotations for internal nodes (and edges) can then be accomplished by a number of systems. Perhaps the easiest is to recognize that every internal node has a closing ')' character associated with it. The offset of that closing parentheses from the start of the string, is thus a unique identifier for the node. If we were not "exporting" these ids (and making client code learn the system), then the fact that the system is a bit cryptic (OK, more than a *bit* cryptic) would not cause headaches for clients. Just a thought. I don't have serious objections to coming up with a clear system of tagging edges and nodes with labels, but we may not need it. all the best, Mark [snip] |
From: Michael E. <mi...@sf...> - 2010-05-27 02:07:57
|
Just to be clear, it is PAML not PAUP that uses '$' to label branches. My mistake. It actually uses one character to label an edge, and another character to label all edges within a subtree. It doesn't use anything to label nodes but it's an obvious extension. This is a side-issue but thought I should correct my earlier error. Mick ----- Original Message ----- From: "Jeet Sukumaran" <je...@ku...> To: "Michael Elliot" <mi...@sf...> Cc: ncl...@li... Sent: Wednesday, May 26, 2010 6:57:07 PM GMT -08:00 US/Canada Pacific Subject: Re: [Ncl-devel] annotation API for NCL Hi Michael, I completely agree with your second approach to this (the 'better solution' as you call it). As noted, personally I would *far* prefer to deal with an in-memory representation of a tree, complete with rich annotations, rather then having to write on my own Newick parser on top of NCL, especially one specialized to deal with (another) variant/customization/extension of Newick. Your second suggestion accommodates both this, as well as allows the possibility of by-passing NCL's tree instantiation and grabbing the '#$-Newick' string directly: in other words, the client code has the choice. Ideal. As for 'boost:any', this is tempting, but right now the NCL build is pretty clean and straightforward. Would we be throwing that away, or at least compromising it, by making Boost a dependency? -- jeet p.s. This is the first time I've heard of the "#" and "$" PAUP convention. Interesting! On 5/27/10 6:37 AM, Michael Elliot wrote: > Re. metadata for tree elements > > I'm just tossing out ideas here so bear with me if this is a bit wacky. As most of you know I'm quite new to the library and its applications but I'll get to grips with it sooner or later. > > My understanding is that trees are stored as newick strings within NCL. In order to annotate nodes/edges I see two possible approaches. > > First, we can modify the newick string representation internally to provide ids for each node and edge in a tree. I envisage using something similar to the approach used in Paup, in which '$' is used as an edge identifier. Let's say we use '#' as a node identifier and '$' as an edge identifier in the same way that ':' is used as an edgeLength identifier. > > So our internal newick representation goes from: > > ((A:1,B:1)AB:1,C:2)R:0; > > to: > > ((A#n1$e1:1,B#n2$e2:1)AB#n3$e3:1,C#n4$e4:2)R#n5$e5:0; > > Internally, we could then associate metadata in a hash table based on the ids in the tree. > > This has the obvious drawback that client code must know the node and edge ids somehow in order to fetch the metadata. One can image having something like: > > std::vector<NxsString> myNodeIds = treeBlock->getNodeIds(unsigned int treeId); > > Not terribly intuitive to map node ids onto nodes, though. > > I think a better solution is simply to represent trees as actual trees accompanied by preorder and postorder iterators, in memory. At face value this would be a much more radical redesign of the library. But not necessarily. What we could do is use a modified internal tree representation like "((A#n1$e1:1,B#n2$e2:1)AB#n3$e3:1,C#n4$e4:2)R#n5$e5:0;" and store a hash table of metadata as described above; but simply generate a true tree data structure on the fly from the modified newick representation when some specific tree metadata is requested. > > So the tree storage would be a set of modified newick strings. But the newick string would be used to generate a true tree data structure using client code like: > > TreeStructure * struct = myTreeBlock->getTreeStructure(unsigned int id); //<- a tree structure is generated on the fly from the stored newick string > TreeStructure::iterator it = struct->preorder_begin(); > while (it != struct->preorder_end()) { > NxsString nodeMetadata = *it; // NxsString-formatted metadata is looked up in a pre-stored hash table > NxsString nodeId = it.id()/ > // do something with the metadata.... > ++it; > } > > Just tossing out ideas here. Storing trees as strings and using them to generate tree data structures on the fly is quite an efficient way of doing things in terms of memory use and speed (for example I have a very simple tree class with pre and postorder iterators that can generate the complete ncbi taxonomy from an in-memory newick string in a few milliseconds). > > As for the strong typing of c++ - metadata could be stored as a sequence of "boost::any" objects and we could have client code request each metadata item in the format it can handle, otherwise ignore the metadata if it cannot be converted to the requested type. I think it really is up to client code to know what types of data it can handle. > > Mick > > ----- Original Message ----- > From: "Jeet Sukumaran"<je...@ku...> > Cc: "ncl-devel"<ncl...@li...> > Sent: Tuesday, May 25, 2010 9:18:54 PM GMT -08:00 US/Canada Pacific > Subject: Re: [Ncl-devel] annotation API for NCL > > I read this briefly earlier this morning (yes, "morning", thanks to > lingering jet lag + baby feeding times, I have been experiencing this > phenomenon quite a bit recently), but now the link seems dead ... > > Anyway, I think the proposed design makes sense, if I remember correctly > .... > Using the Git-ique metaphors of "plumbing" vs. "porcelain": > The "plumbing" in this case is the data structure associated with the > reader, which stores the triplets, include the pointer to the > appropriate Nexus objects. > As you note, added syntactic sugar would function as "porcelain", > allowing for easier access to the annotations. > Am I right in remembering that, with the proposed porcelain, if I want > all the annotations referring to a Tree object, I can just ask the > Tree object for all annotations that reference it, and I get back a > vector (or list)? > I guess the enum mechanism + casting is the only way to reconcile the > flexibility of annotations' referents with the strong typing of C++. > It would be great if the porcelain could wrap this up as much as possible. > > The problem of annotating tree edges/nodes and character > columns/rows/cells remains. For the former, I personally would prefer to > avoid the client-side cost/hassle of tracking a particular node's > post-order traversal index. Instead, I think that if client code wants > to access annotations on tree components, it would be perfectly fair to > expect them to ask for a NCL Tree object and deal or otherwise harvest > info from that. That way, edge and node annotations can be managed using > the the same "porcelain" as for any other "first class" NCL objects. > > The character matrix case is a little more complicated, as a full > implementation of a NeXML spec'd character object model requires a > fat/rich stack of fat/rich classes (in Asia, we might say "prosperous"). > If this needs and is going to be done as part of the GSoC NCL/NeXML > project anyway, and if the implementation ends up with character > cells/rows/columns all being "first class" NCL objects, then the > annotations might be bundled up with these as part of their porcelain. > Personally, I would be quite happy for a "prosperous" character object > model in NCL. But I am not the one doing the coding! If we do not go > that route, then maybe a specialized data structure associated with a > character matrix that can facultatively take (a) a row index, (b) a > column index or (c) a row/column = cell index and return the associated > list of annotations might be desirable porcelain. > > -- jeet > On 5/26/10 4:05 AM, Mark Holder wrote: > >> Hi ncl-devel, >> This email was going to follow up on a conversation that was started on a thread that I kicked off when announcing the fact that NCL2.1 now has reasonable documentation, but I think that it is better to use a Wiki to launch this discussion rather than lots of email threads. I'm certainly happy to discuss the issues via email (rather on the wiki), but I thought it would be best to refer interested parties to https://sourceforge.net/apps/mediawiki/ncl/index.php?title=AnnotationAPIDiscussion >> for the initial message in the discussion. >> >> The general topic was, "How should NCL store generic annotations and make them available to client code?" >> >> The motivation to get moving on this is the fact that Mick Elliot is adding support for nexml and phyloxml as a part of the Google Summer of Code, so we'll need to have a decision soon (next week). >> >> >> >> I'm honestly not sure who has access to the Wiki mentioned. I just enabled it as a feature through sourceforge this morning. Let me know if you have problems reading or writing, and I'll try to figure out how it is administered. >> >> >> all the best, >> Mark >> >> >> Mark Holder >> >> mth...@ku... >> http://phylo.bio.ku.edu/mark-holder >> >> ============================================== >> 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 >> ============================================== >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Ncl-devel mailing list >> Ncl...@li... >> https://lists.sourceforge.net/lists/listinfo/ncl-devel >> >> >> > > -- -------------------------------------- Jeet Sukumaran -------------------------------------- Division of Herpetology Department of Ecology and Evolutionary Biology / Biodiversity Institute University of Kansas Dyche Hall 1345 Jayhawk Blvd Lawrence KS 66045-7561 -------------------------------------- Phone: 785-864-3439 Fax: 785-864-5335 E-mail(s): je...@ku... -------------------------------------- Personal Pages: http://jeetworks.org/ Photograph Galleries: http://jeet.smugmug.com/ Phylogeography and Biogeography Blog: http://geodendron.blogspot.com -------------------------------------- |
From: Jeet S. <je...@ku...> - 2010-05-27 01:57:42
|
Hi Michael, I completely agree with your second approach to this (the 'better solution' as you call it). As noted, personally I would *far* prefer to deal with an in-memory representation of a tree, complete with rich annotations, rather then having to write on my own Newick parser on top of NCL, especially one specialized to deal with (another) variant/customization/extension of Newick. Your second suggestion accommodates both this, as well as allows the possibility of by-passing NCL's tree instantiation and grabbing the '#$-Newick' string directly: in other words, the client code has the choice. Ideal. As for 'boost:any', this is tempting, but right now the NCL build is pretty clean and straightforward. Would we be throwing that away, or at least compromising it, by making Boost a dependency? -- jeet p.s. This is the first time I've heard of the "#" and "$" PAUP convention. Interesting! On 5/27/10 6:37 AM, Michael Elliot wrote: > Re. metadata for tree elements > > I'm just tossing out ideas here so bear with me if this is a bit wacky. As most of you know I'm quite new to the library and its applications but I'll get to grips with it sooner or later. > > My understanding is that trees are stored as newick strings within NCL. In order to annotate nodes/edges I see two possible approaches. > > First, we can modify the newick string representation internally to provide ids for each node and edge in a tree. I envisage using something similar to the approach used in Paup, in which '$' is used as an edge identifier. Let's say we use '#' as a node identifier and '$' as an edge identifier in the same way that ':' is used as an edgeLength identifier. > > So our internal newick representation goes from: > > ((A:1,B:1)AB:1,C:2)R:0; > > to: > > ((A#n1$e1:1,B#n2$e2:1)AB#n3$e3:1,C#n4$e4:2)R#n5$e5:0; > > Internally, we could then associate metadata in a hash table based on the ids in the tree. > > This has the obvious drawback that client code must know the node and edge ids somehow in order to fetch the metadata. One can image having something like: > > std::vector<NxsString> myNodeIds = treeBlock->getNodeIds(unsigned int treeId); > > Not terribly intuitive to map node ids onto nodes, though. > > I think a better solution is simply to represent trees as actual trees accompanied by preorder and postorder iterators, in memory. At face value this would be a much more radical redesign of the library. But not necessarily. What we could do is use a modified internal tree representation like "((A#n1$e1:1,B#n2$e2:1)AB#n3$e3:1,C#n4$e4:2)R#n5$e5:0;" and store a hash table of metadata as described above; but simply generate a true tree data structure on the fly from the modified newick representation when some specific tree metadata is requested. > > So the tree storage would be a set of modified newick strings. But the newick string would be used to generate a true tree data structure using client code like: > > TreeStructure * struct = myTreeBlock->getTreeStructure(unsigned int id); //<- a tree structure is generated on the fly from the stored newick string > TreeStructure::iterator it = struct->preorder_begin(); > while (it != struct->preorder_end()) { > NxsString nodeMetadata = *it; // NxsString-formatted metadata is looked up in a pre-stored hash table > NxsString nodeId = it.id()/ > // do something with the metadata.... > ++it; > } > > Just tossing out ideas here. Storing trees as strings and using them to generate tree data structures on the fly is quite an efficient way of doing things in terms of memory use and speed (for example I have a very simple tree class with pre and postorder iterators that can generate the complete ncbi taxonomy from an in-memory newick string in a few milliseconds). > > As for the strong typing of c++ - metadata could be stored as a sequence of "boost::any" objects and we could have client code request each metadata item in the format it can handle, otherwise ignore the metadata if it cannot be converted to the requested type. I think it really is up to client code to know what types of data it can handle. > > Mick > > ----- Original Message ----- > From: "Jeet Sukumaran"<je...@ku...> > Cc: "ncl-devel"<ncl...@li...> > Sent: Tuesday, May 25, 2010 9:18:54 PM GMT -08:00 US/Canada Pacific > Subject: Re: [Ncl-devel] annotation API for NCL > > I read this briefly earlier this morning (yes, "morning", thanks to > lingering jet lag + baby feeding times, I have been experiencing this > phenomenon quite a bit recently), but now the link seems dead ... > > Anyway, I think the proposed design makes sense, if I remember correctly > .... > Using the Git-ique metaphors of "plumbing" vs. "porcelain": > The "plumbing" in this case is the data structure associated with the > reader, which stores the triplets, include the pointer to the > appropriate Nexus objects. > As you note, added syntactic sugar would function as "porcelain", > allowing for easier access to the annotations. > Am I right in remembering that, with the proposed porcelain, if I want > all the annotations referring to a Tree object, I can just ask the > Tree object for all annotations that reference it, and I get back a > vector (or list)? > I guess the enum mechanism + casting is the only way to reconcile the > flexibility of annotations' referents with the strong typing of C++. > It would be great if the porcelain could wrap this up as much as possible. > > The problem of annotating tree edges/nodes and character > columns/rows/cells remains. For the former, I personally would prefer to > avoid the client-side cost/hassle of tracking a particular node's > post-order traversal index. Instead, I think that if client code wants > to access annotations on tree components, it would be perfectly fair to > expect them to ask for a NCL Tree object and deal or otherwise harvest > info from that. That way, edge and node annotations can be managed using > the the same "porcelain" as for any other "first class" NCL objects. > > The character matrix case is a little more complicated, as a full > implementation of a NeXML spec'd character object model requires a > fat/rich stack of fat/rich classes (in Asia, we might say "prosperous"). > If this needs and is going to be done as part of the GSoC NCL/NeXML > project anyway, and if the implementation ends up with character > cells/rows/columns all being "first class" NCL objects, then the > annotations might be bundled up with these as part of their porcelain. > Personally, I would be quite happy for a "prosperous" character object > model in NCL. But I am not the one doing the coding! If we do not go > that route, then maybe a specialized data structure associated with a > character matrix that can facultatively take (a) a row index, (b) a > column index or (c) a row/column = cell index and return the associated > list of annotations might be desirable porcelain. > > -- jeet > On 5/26/10 4:05 AM, Mark Holder wrote: > >> Hi ncl-devel, >> This email was going to follow up on a conversation that was started on a thread that I kicked off when announcing the fact that NCL2.1 now has reasonable documentation, but I think that it is better to use a Wiki to launch this discussion rather than lots of email threads. I'm certainly happy to discuss the issues via email (rather on the wiki), but I thought it would be best to refer interested parties to https://sourceforge.net/apps/mediawiki/ncl/index.php?title=AnnotationAPIDiscussion >> for the initial message in the discussion. >> >> The general topic was, "How should NCL store generic annotations and make them available to client code?" >> >> The motivation to get moving on this is the fact that Mick Elliot is adding support for nexml and phyloxml as a part of the Google Summer of Code, so we'll need to have a decision soon (next week). >> >> >> >> I'm honestly not sure who has access to the Wiki mentioned. I just enabled it as a feature through sourceforge this morning. Let me know if you have problems reading or writing, and I'll try to figure out how it is administered. >> >> >> all the best, >> Mark >> >> >> Mark Holder >> >> mth...@ku... >> http://phylo.bio.ku.edu/mark-holder >> >> ============================================== >> 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 >> ============================================== >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Ncl-devel mailing list >> Ncl...@li... >> https://lists.sourceforge.net/lists/listinfo/ncl-devel >> >> >> > > -- -------------------------------------- Jeet Sukumaran -------------------------------------- Division of Herpetology Department of Ecology and Evolutionary Biology / Biodiversity Institute University of Kansas Dyche Hall 1345 Jayhawk Blvd Lawrence KS 66045-7561 -------------------------------------- Phone: 785-864-3439 Fax: 785-864-5335 E-mail(s): je...@ku... -------------------------------------- Personal Pages: http://jeetworks.org/ Photograph Galleries: http://jeet.smugmug.com/ Phylogeography and Biogeography Blog: http://geodendron.blogspot.com -------------------------------------- |
From: Michael E. <mi...@sf...> - 2010-05-26 22:37:41
|
Re. metadata for tree elements I'm just tossing out ideas here so bear with me if this is a bit wacky. As most of you know I'm quite new to the library and its applications but I'll get to grips with it sooner or later. My understanding is that trees are stored as newick strings within NCL. In order to annotate nodes/edges I see two possible approaches. First, we can modify the newick string representation internally to provide ids for each node and edge in a tree. I envisage using something similar to the approach used in Paup, in which '$' is used as an edge identifier. Let's say we use '#' as a node identifier and '$' as an edge identifier in the same way that ':' is used as an edgeLength identifier. So our internal newick representation goes from: ((A:1,B:1)AB:1,C:2)R:0; to: ((A#n1$e1:1,B#n2$e2:1)AB#n3$e3:1,C#n4$e4:2)R#n5$e5:0; Internally, we could then associate metadata in a hash table based on the ids in the tree. This has the obvious drawback that client code must know the node and edge ids somehow in order to fetch the metadata. One can image having something like: std::vector<NxsString> myNodeIds = treeBlock->getNodeIds(unsigned int treeId); Not terribly intuitive to map node ids onto nodes, though. I think a better solution is simply to represent trees as actual trees accompanied by preorder and postorder iterators, in memory. At face value this would be a much more radical redesign of the library. But not necessarily. What we could do is use a modified internal tree representation like "((A#n1$e1:1,B#n2$e2:1)AB#n3$e3:1,C#n4$e4:2)R#n5$e5:0;" and store a hash table of metadata as described above; but simply generate a true tree data structure on the fly from the modified newick representation when some specific tree metadata is requested. So the tree storage would be a set of modified newick strings. But the newick string would be used to generate a true tree data structure using client code like: TreeStructure * struct = myTreeBlock->getTreeStructure(unsigned int id); // <- a tree structure is generated on the fly from the stored newick string TreeStructure::iterator it = struct->preorder_begin(); while (it != struct->preorder_end()) { NxsString nodeMetadata = *it; // NxsString-formatted metadata is looked up in a pre-stored hash table NxsString nodeId = it.id()/ // do something with the metadata.... ++it; } Just tossing out ideas here. Storing trees as strings and using them to generate tree data structures on the fly is quite an efficient way of doing things in terms of memory use and speed (for example I have a very simple tree class with pre and postorder iterators that can generate the complete ncbi taxonomy from an in-memory newick string in a few milliseconds). As for the strong typing of c++ - metadata could be stored as a sequence of "boost::any" objects and we could have client code request each metadata item in the format it can handle, otherwise ignore the metadata if it cannot be converted to the requested type. I think it really is up to client code to know what types of data it can handle. Mick ----- Original Message ----- From: "Jeet Sukumaran" <je...@ku...> Cc: "ncl-devel" <ncl...@li...> Sent: Tuesday, May 25, 2010 9:18:54 PM GMT -08:00 US/Canada Pacific Subject: Re: [Ncl-devel] annotation API for NCL I read this briefly earlier this morning (yes, "morning", thanks to lingering jet lag + baby feeding times, I have been experiencing this phenomenon quite a bit recently), but now the link seems dead ... Anyway, I think the proposed design makes sense, if I remember correctly .... Using the Git-ique metaphors of "plumbing" vs. "porcelain": The "plumbing" in this case is the data structure associated with the reader, which stores the triplets, include the pointer to the appropriate Nexus objects. As you note, added syntactic sugar would function as "porcelain", allowing for easier access to the annotations. Am I right in remembering that, with the proposed porcelain, if I want all the annotations referring to a Tree object, I can just ask the Tree object for all annotations that reference it, and I get back a vector (or list)? I guess the enum mechanism + casting is the only way to reconcile the flexibility of annotations' referents with the strong typing of C++. It would be great if the porcelain could wrap this up as much as possible. The problem of annotating tree edges/nodes and character columns/rows/cells remains. For the former, I personally would prefer to avoid the client-side cost/hassle of tracking a particular node's post-order traversal index. Instead, I think that if client code wants to access annotations on tree components, it would be perfectly fair to expect them to ask for a NCL Tree object and deal or otherwise harvest info from that. That way, edge and node annotations can be managed using the the same "porcelain" as for any other "first class" NCL objects. The character matrix case is a little more complicated, as a full implementation of a NeXML spec'd character object model requires a fat/rich stack of fat/rich classes (in Asia, we might say "prosperous"). If this needs and is going to be done as part of the GSoC NCL/NeXML project anyway, and if the implementation ends up with character cells/rows/columns all being "first class" NCL objects, then the annotations might be bundled up with these as part of their porcelain. Personally, I would be quite happy for a "prosperous" character object model in NCL. But I am not the one doing the coding! If we do not go that route, then maybe a specialized data structure associated with a character matrix that can facultatively take (a) a row index, (b) a column index or (c) a row/column = cell index and return the associated list of annotations might be desirable porcelain. -- jeet On 5/26/10 4:05 AM, Mark Holder wrote: > Hi ncl-devel, > This email was going to follow up on a conversation that was started on a thread that I kicked off when announcing the fact that NCL2.1 now has reasonable documentation, but I think that it is better to use a Wiki to launch this discussion rather than lots of email threads. I'm certainly happy to discuss the issues via email (rather on the wiki), but I thought it would be best to refer interested parties to https://sourceforge.net/apps/mediawiki/ncl/index.php?title=AnnotationAPIDiscussion > for the initial message in the discussion. > > The general topic was, "How should NCL store generic annotations and make them available to client code?" > > The motivation to get moving on this is the fact that Mick Elliot is adding support for nexml and phyloxml as a part of the Google Summer of Code, so we'll need to have a decision soon (next week). > > > > I'm honestly not sure who has access to the Wiki mentioned. I just enabled it as a feature through sourceforge this morning. Let me know if you have problems reading or writing, and I'll try to figure out how it is administered. > > > all the best, > Mark > > > Mark Holder > > mth...@ku... > http://phylo.bio.ku.edu/mark-holder > > ============================================== > 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 > ============================================== > > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Ncl-devel mailing list > Ncl...@li... > https://lists.sourceforge.net/lists/listinfo/ncl-devel > > -- -------------------------------------- Jeet Sukumaran -------------------------------------- Division of Herpetology Department of Ecology and Evolutionary Biology / Biodiversity Institute University of Kansas Dyche Hall 1345 Jayhawk Blvd Lawrence KS 66045-7561 -------------------------------------- Phone: 785-864-3439 Fax: 785-864-5335 E-mail(s): je...@ku... -------------------------------------- Personal Pages: http://jeetworks.org/ Photograph Galleries: http://jeet.smugmug.com/ Phylogeography and Biogeography Blog: http://geodendron.blogspot.com -------------------------------------- ------------------------------------------------------------------------------ _______________________________________________ Ncl-devel mailing list Ncl...@li... https://lists.sourceforge.net/lists/listinfo/ncl-devel |
From: Jeet S. <je...@ku...> - 2010-05-26 04:19:11
|
I read this briefly earlier this morning (yes, "morning", thanks to lingering jet lag + baby feeding times, I have been experiencing this phenomenon quite a bit recently), but now the link seems dead ... Anyway, I think the proposed design makes sense, if I remember correctly .... Using the Git-ique metaphors of "plumbing" vs. "porcelain": The "plumbing" in this case is the data structure associated with the reader, which stores the triplets, include the pointer to the appropriate Nexus objects. As you note, added syntactic sugar would function as "porcelain", allowing for easier access to the annotations. Am I right in remembering that, with the proposed porcelain, if I want all the annotations referring to a Tree object, I can just ask the Tree object for all annotations that reference it, and I get back a vector (or list)? I guess the enum mechanism + casting is the only way to reconcile the flexibility of annotations' referents with the strong typing of C++. It would be great if the porcelain could wrap this up as much as possible. The problem of annotating tree edges/nodes and character columns/rows/cells remains. For the former, I personally would prefer to avoid the client-side cost/hassle of tracking a particular node's post-order traversal index. Instead, I think that if client code wants to access annotations on tree components, it would be perfectly fair to expect them to ask for a NCL Tree object and deal or otherwise harvest info from that. That way, edge and node annotations can be managed using the the same "porcelain" as for any other "first class" NCL objects. The character matrix case is a little more complicated, as a full implementation of a NeXML spec'd character object model requires a fat/rich stack of fat/rich classes (in Asia, we might say "prosperous"). If this needs and is going to be done as part of the GSoC NCL/NeXML project anyway, and if the implementation ends up with character cells/rows/columns all being "first class" NCL objects, then the annotations might be bundled up with these as part of their porcelain. Personally, I would be quite happy for a "prosperous" character object model in NCL. But I am not the one doing the coding! If we do not go that route, then maybe a specialized data structure associated with a character matrix that can facultatively take (a) a row index, (b) a column index or (c) a row/column = cell index and return the associated list of annotations might be desirable porcelain. -- jeet On 5/26/10 4:05 AM, Mark Holder wrote: > Hi ncl-devel, > This email was going to follow up on a conversation that was started on a thread that I kicked off when announcing the fact that NCL2.1 now has reasonable documentation, but I think that it is better to use a Wiki to launch this discussion rather than lots of email threads. I'm certainly happy to discuss the issues via email (rather on the wiki), but I thought it would be best to refer interested parties to https://sourceforge.net/apps/mediawiki/ncl/index.php?title=AnnotationAPIDiscussion > for the initial message in the discussion. > > The general topic was, "How should NCL store generic annotations and make them available to client code?" > > The motivation to get moving on this is the fact that Mick Elliot is adding support for nexml and phyloxml as a part of the Google Summer of Code, so we'll need to have a decision soon (next week). > > > > I'm honestly not sure who has access to the Wiki mentioned. I just enabled it as a feature through sourceforge this morning. Let me know if you have problems reading or writing, and I'll try to figure out how it is administered. > > > all the best, > Mark > > > Mark Holder > > mth...@ku... > http://phylo.bio.ku.edu/mark-holder > > ============================================== > 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 > ============================================== > > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Ncl-devel mailing list > Ncl...@li... > https://lists.sourceforge.net/lists/listinfo/ncl-devel > > -- -------------------------------------- Jeet Sukumaran -------------------------------------- Division of Herpetology Department of Ecology and Evolutionary Biology / Biodiversity Institute University of Kansas Dyche Hall 1345 Jayhawk Blvd Lawrence KS 66045-7561 -------------------------------------- Phone: 785-864-3439 Fax: 785-864-5335 E-mail(s): je...@ku... -------------------------------------- Personal Pages: http://jeetworks.org/ Photograph Galleries: http://jeet.smugmug.com/ Phylogeography and Biogeography Blog: http://geodendron.blogspot.com -------------------------------------- |
From: Jeet S. <jee...@gm...> - 2010-05-26 04:15:49
|
I read this briefly earlier this morning (yes, "morning", thanks to lingering jet lag + baby feeding times, I have been experiencing this phenomenon quite a bit recently), but now the link seems dead ... Anyway, I think the proposed design makes sense, if I remember correctly .... Using the Git-ique metaphors of "plumbing" vs. "porcelain": The "plumbing" in this case is the data structure associated with the reader, which stores the triplets, include the pointer to the appropriate Nexus objects. As you note, added syntactic sugar would function as "porcelain", allowing for easier access to the annotations. Am I right in remembering that, with the proposed porcelain, if I want all the annotations referring to a Tree object, I can just ask the Tree object for all annotations that reference it, and I get back a vector (or list)? I guess the enum mechanism + casting is the only way to reconcile the flexibility of annotations' referents with the strong typing of C++. It would be great if the porcelain could wrap this up as much as possible. The problem of annotating tree edges/nodes and character columns/rows/cells remains. For the former, I personally would prefer to avoid the client-side cost/hassle of tracking a particular node's post-order traversal index. Instead, I think that if client code wants to access annotations on tree components, it would be perfectly fair to expect them to ask for a NCL Tree object and deal or otherwise harvest info from that. That way, edge and node annotations can be managed using the the same "porcelain" as for any other "first class" NCL objects. The character matrix case is a little more complicated, as a full implementation of a NeXML spec'd character object model requires a fat/rich stack of fat/rich classes (in Asia, we might say "prosperous"). If this needs and is going to be done as part of the GSoC NCL/NeXML project anyway, and if the implementation ends up with character cells/rows/columns all being "first class" NCL objects, then the annotations might be bundled up with these as part of their porcelain. Personally, I would be quite happy for a "prosperous" character object model in NCL. But I am not the one doing the coding! If we do not go that route, then maybe a specialized data structure associated with a character matrix that can facultatively take (a) a row index, (b) a column index or (c) a row/column = cell index and return the associated list of annotations might be desirable porcelain. -- jeet On 5/26/10 4:05 AM, Mark Holder wrote: > Hi ncl-devel, > This email was going to follow up on a conversation that was started on a thread that I kicked off when announcing the fact that NCL2.1 now has reasonable documentation, but I think that it is better to use a Wiki to launch this discussion rather than lots of email threads. I'm certainly happy to discuss the issues via email (rather on the wiki), but I thought it would be best to refer interested parties to https://sourceforge.net/apps/mediawiki/ncl/index.php?title=AnnotationAPIDiscussion > for the initial message in the discussion. > > The general topic was, "How should NCL store generic annotations and make them available to client code?" > > The motivation to get moving on this is the fact that Mick Elliot is adding support for nexml and phyloxml as a part of the Google Summer of Code, so we'll need to have a decision soon (next week). > > > > I'm honestly not sure who has access to the Wiki mentioned. I just enabled it as a feature through sourceforge this morning. Let me know if you have problems reading or writing, and I'll try to figure out how it is administered. > > > all the best, > Mark > > > Mark Holder > > mth...@ku... > http://phylo.bio.ku.edu/mark-holder > > ============================================== > 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 > ============================================== > > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Ncl-devel mailing list > Ncl...@li... > https://lists.sourceforge.net/lists/listinfo/ncl-devel > > |
From: Hilmar L. <hl...@ne...> - 2010-05-25 22:40:23
|
I think you also have to make sure the user is in the editor group here: https://sourceforge.net/apps/mediawiki/ncl/index.php?title=Special:UserRights -hilmar On May 25, 2010, at 2:37 PM, Rutger Vos wrote: > Everyone can read the blog, but to write you'll need a sourceforge > account and to be added to the project (I'm "rvos", you have to add me > as a contributor). Not sure if you'll have write access even then, but > I think you do. > > On Tue, May 25, 2010 at 9:05 PM, Mark Holder <mth...@ku...> wrote: >> Hi ncl-devel, >> This email was going to follow up on a conversation that was >> started on a thread that I kicked off when announcing the fact that >> NCL2.1 now has reasonable documentation, but I think that it is >> better to use a Wiki to launch this discussion rather than lots of >> email threads. I'm certainly happy to discuss the issues via email >> (rather on the wiki), but I thought it would be best to refer >> interested parties to https://sourceforge.net/apps/mediawiki/ncl/index.php?title=AnnotationAPIDiscussion >> for the initial message in the discussion. >> >> The general topic was, "How should NCL store generic >> annotations and make them available to client code?" >> >> The motivation to get moving on this is the fact that Mick >> Elliot is adding support for nexml and phyloxml as a part of the >> Google Summer of Code, so we'll need to have a decision soon (next >> week). >> >> >> >> I'm honestly not sure who has access to the Wiki mentioned. >> I just enabled it as a feature through sourceforge this morning. >> Let me know if you have problems reading or writing, and I'll try >> to figure out how it is administered. >> >> >> all the best, >> Mark >> >> >> Mark Holder >> >> mth...@ku... >> http://phylo.bio.ku.edu/mark-holder >> >> ============================================== >> 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 >> ============================================== >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Ncl-devel mailing list >> Ncl...@li... >> https://lists.sourceforge.net/lists/listinfo/ncl-devel >> > > > > -- > Dr. Rutger A. Vos > School of Biological Sciences > Philip Lyle Building, Level 4 > University of Reading > Reading > RG6 6BX > United Kingdom > Tel: +44 (0) 118 378 7535 > http://www.nexml.org > http://rutgervos.blogspot.com > > ------------------------------------------------------------------------------ > > _______________________________________________ > Ncl-devel mailing list > Ncl...@li... > https://lists.sourceforge.net/lists/listinfo/ncl-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Rutger V. <rut...@gm...> - 2010-05-25 20:38:01
|
Everyone can read the blog, but to write you'll need a sourceforge account and to be added to the project (I'm "rvos", you have to add me as a contributor). Not sure if you'll have write access even then, but I think you do. On Tue, May 25, 2010 at 9:05 PM, Mark Holder <mth...@ku...> wrote: > Hi ncl-devel, > This email was going to follow up on a conversation that was started on a thread that I kicked off when announcing the fact that NCL2.1 now has reasonable documentation, but I think that it is better to use a Wiki to launch this discussion rather than lots of email threads. I'm certainly happy to discuss the issues via email (rather on the wiki), but I thought it would be best to refer interested parties to https://sourceforge.net/apps/mediawiki/ncl/index.php?title=AnnotationAPIDiscussion > for the initial message in the discussion. > > The general topic was, "How should NCL store generic annotations and make them available to client code?" > > The motivation to get moving on this is the fact that Mick Elliot is adding support for nexml and phyloxml as a part of the Google Summer of Code, so we'll need to have a decision soon (next week). > > > > I'm honestly not sure who has access to the Wiki mentioned. I just enabled it as a feature through sourceforge this morning. Let me know if you have problems reading or writing, and I'll try to figure out how it is administered. > > > all the best, > Mark > > > Mark Holder > > mth...@ku... > http://phylo.bio.ku.edu/mark-holder > > ============================================== > 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 > ============================================== > > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Ncl-devel mailing list > Ncl...@li... > https://lists.sourceforge.net/lists/listinfo/ncl-devel > -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com |
From: Mark H. <mth...@ku...> - 2010-05-25 20:05:31
|
Hi ncl-devel, This email was going to follow up on a conversation that was started on a thread that I kicked off when announcing the fact that NCL2.1 now has reasonable documentation, but I think that it is better to use a Wiki to launch this discussion rather than lots of email threads. I'm certainly happy to discuss the issues via email (rather on the wiki), but I thought it would be best to refer interested parties to https://sourceforge.net/apps/mediawiki/ncl/index.php?title=AnnotationAPIDiscussion for the initial message in the discussion. The general topic was, "How should NCL store generic annotations and make them available to client code?" The motivation to get moving on this is the fact that Mick Elliot is adding support for nexml and phyloxml as a part of the Google Summer of Code, so we'll need to have a decision soon (next week). I'm honestly not sure who has access to the Wiki mentioned. I just enabled it as a feature through sourceforge this morning. Let me know if you have problems reading or writing, and I'll try to figure out how it is administered. all the best, Mark Mark Holder mth...@ku... http://phylo.bio.ku.edu/mark-holder ============================================== 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 ============================================== |