Menu
▾
▴
ncl-devel
|
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 ============================================== |
|
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: 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: 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: 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 -------------------------------------- |
Thanks for helping keep SourceForge clean.
X