You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
(41) |
May
(41) |
Jun
(50) |
Jul
(14) |
Aug
(21) |
Sep
(37) |
Oct
(8) |
Nov
(4) |
Dec
(135) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(145) |
Feb
(110) |
Mar
(216) |
Apr
(101) |
May
(42) |
Jun
(42) |
Jul
(23) |
Aug
(17) |
Sep
(33) |
Oct
(15) |
Nov
(18) |
Dec
(6) |
2011 |
Jan
(8) |
Feb
(10) |
Mar
(8) |
Apr
(41) |
May
(48) |
Jun
(62) |
Jul
(7) |
Aug
(9) |
Sep
(7) |
Oct
(11) |
Nov
(49) |
Dec
(1) |
2012 |
Jan
(17) |
Feb
(63) |
Mar
(4) |
Apr
(13) |
May
(17) |
Jun
(21) |
Jul
(10) |
Aug
(10) |
Sep
|
Oct
|
Nov
|
Dec
(16) |
2013 |
Jan
(10) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Rutger V. <rut...@gm...> - 2010-02-15 11:44:08
|
I would like to hear what use cases Ryan (the original poster of the ticket) had in mind and what needs to happen to meet his requirements. Is there a dryad<->treebase interoperability use case you're trying to implement? On Mon, Feb 15, 2010 at 5:49 PM, Hilmar Lapp <hl...@ne...> wrote: > > On Feb 14, 2010, at 8:00 PM, Matt wrote: > >> I suppose though that you could add many lat/longs to one cell (through >> specimens)? > > Yes, attaching to OTUs should not preclude the ability to attach those to > cells, and in principle one should be able to attach any number of > geo-coordinates. > > It's an interesting question though whether the geo-coordinate as a property > of the specimen should (automatically?) propagate to the cell (or OTU) that > the specimen is attached to. In principle, I suppose the answer should be > yes, and in a perfect Linked Data world a reasoning framework or phylo-data > browser should be able to look up the specimen metadata if a specimen is > attached, and infer the geo-coordinates for the cell or OTU. > > -hilmar > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > -- 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-02-15 10:19:06
|
On Feb 14, 2010, at 8:00 PM, Matt wrote: > I suppose though that you could add many lat/longs to one cell > (through specimens)? Yes, attaching to OTUs should not preclude the ability to attach those to cells, and in principle one should be able to attach any number of geo-coordinates. It's an interesting question though whether the geo-coordinate as a property of the specimen should (automatically?) propagate to the cell (or OTU) that the specimen is attached to. In principle, I suppose the answer should be yes, and in a perfect Linked Data world a reasoning framework or phylo-data browser should be able to look up the specimen metadata if a specimen is attached, and infer the geo-coordinates for the cell or OTU. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Matt <dia...@gm...> - 2010-02-14 20:00:29
|
Will there be other nodes/places to add lat/long at? Lat/long on cells seems to be problematic in some ways, though it's preferable to attaching it to row segments. For one, it fails for practically all morphological matrices in which OTUs have many specimens. For sequences there are also scenarios where a cell may be derived from many specimens (consensus sequences). I suppose though that you could add many lat/longs to one cell (through specimens?)? Matt On Sat, Feb 13, 2010 at 11:01 AM, Rutger Vos <rut...@gm...> wrote: > OK, maybe it is better to attach it to the OTU, I hadn't really > considered that because in the db the coordinates are attached to row > segments, but I suppose this makes more sense. > > On Fri, Feb 12, 2010 at 11:38 PM, Hilmar Lapp <hl...@ne...> wrote: >> (cross-posting to cdao re: alignment partitions) >> >> On Feb 11, 2010, at 11:49 PM, Rutger Vos wrote: >> >>> I have added lat/lon as semantic annotations on individual cells using >>> DwC:DecimalLatitude and DwC:DecimalLongitude. [...] >>> >>> Conceivably, verbosity could be reduced by attaching the annotations >>> on <seq> elements instead, but i) although multiple <seq> elements are >>> allowed "in principle", I don't think any of our tools actually >>> support this; ii) cdao has no concept of row segments, so the >>> annotations would be lost if we transformed to nexml to rdf. >> >> If the alignment isn't concatenated with sequences from multiple specimens, >> couldn't (in fact, shouldn't) you attach the lat/long to the OTU, though? >> I.e., where do you attach the specimen currently, and it do you attach >> lat/long in a different fashion than the specimen? >> >> CDAOers: what are status and plans for describing the parts of an alignment >> right now, and is there support, current or planned, for partitions / >> segments of an alignment? >> >> -hilmar >> >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : >> =========================================================== >> >> >> >> > > > > -- > 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 > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > CDAO-discuss mailing list > CDA...@li... > https://lists.sourceforge.net/lists/listinfo/cdao-discuss > |
From: William P. <wil...@ya...> - 2010-02-13 16:53:04
|
In terms of simplicity, it does make sense that the lat-long attach to an OTU -- that's certainly the clearest way to express the most simple possible use case: one specimen per OTU. However, realistically, is is very common for alignments to contain rows derived from several genes and several specimens. So strictly speaking, the lat-long is an attribute of a specimen; a set of characters or genes are observed from that specimen; and the tracing of evolutionary history is derived from the agglomerations of sets of specimen character/genes. So I vote to preserve the ability to attach attributes of specimens (e.g. darwin core metadata, genbank accession numbers, etc) to certain characters, but not others -- and hence not oblige this to be attached to an OTU. Would it be crazy to attached lat/longs to both locations? i.e., if a row has two pairs of lat longs, then the two partitions of that row each of a lat/long pair; but at the same time the OTU is annotated with both pairs. Lastly, TreeBASE's system of annotating row segments allows multiple annotations for the same character elements. e.g. you can attach, say, 20 lat/long pairs and specimen IDs to the same row segment. This is particularly valuable for morphological data, in which the character scorings are applied to a set of identifiable specimens that were examined. But this does not mean that all characters were scored from the same specimens (if for no other reason that some characters can only be scored from males, others only from females). I would hate to see this valuable chain of provenance lost through the effect of "homogenizing" at the point of serialization. bp On Feb 13, 2010, at 11:01 AM, Rutger Vos wrote: > OK, maybe it is better to attach it to the OTU, I hadn't really > considered that because in the db the coordinates are attached to row > segments, but I suppose this makes more sense. > > On Fri, Feb 12, 2010 at 11:38 PM, Hilmar Lapp <hl...@ne...> wrote: >> (cross-posting to cdao re: alignment partitions) >> >> On Feb 11, 2010, at 11:49 PM, Rutger Vos wrote: >> >>> I have added lat/lon as semantic annotations on individual cells using >>> DwC:DecimalLatitude and DwC:DecimalLongitude. [...] >>> >>> Conceivably, verbosity could be reduced by attaching the annotations >>> on <seq> elements instead, but i) although multiple <seq> elements are >>> allowed "in principle", I don't think any of our tools actually >>> support this; ii) cdao has no concept of row segments, so the >>> annotations would be lost if we transformed to nexml to rdf. >> >> If the alignment isn't concatenated with sequences from multiple specimens, >> couldn't (in fact, shouldn't) you attach the lat/long to the OTU, though? >> I.e., where do you attach the specimen currently, and it do you attach >> lat/long in a different fashion than the specimen? >> >> CDAOers: what are status and plans for describing the parts of an alignment >> right now, and is there support, current or planned, for partitions / >> segments of an alignment? >> >> -hilmar |
From: Rutger V. <rut...@gm...> - 2010-02-13 16:02:00
|
OK, maybe it is better to attach it to the OTU, I hadn't really considered that because in the db the coordinates are attached to row segments, but I suppose this makes more sense. On Fri, Feb 12, 2010 at 11:38 PM, Hilmar Lapp <hl...@ne...> wrote: > (cross-posting to cdao re: alignment partitions) > > On Feb 11, 2010, at 11:49 PM, Rutger Vos wrote: > >> I have added lat/lon as semantic annotations on individual cells using >> DwC:DecimalLatitude and DwC:DecimalLongitude. [...] >> >> Conceivably, verbosity could be reduced by attaching the annotations >> on <seq> elements instead, but i) although multiple <seq> elements are >> allowed "in principle", I don't think any of our tools actually >> support this; ii) cdao has no concept of row segments, so the >> annotations would be lost if we transformed to nexml to rdf. > > If the alignment isn't concatenated with sequences from multiple specimens, > couldn't (in fact, shouldn't) you attach the lat/long to the OTU, though? > I.e., where do you attach the specimen currently, and it do you attach > lat/long in a different fashion than the specimen? > > CDAOers: what are status and plans for describing the parts of an alignment > right now, and is there support, current or planned, for partitions / > segments of an alignment? > > -hilmar > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > -- 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: Francisco P. <fra...@uc...> - 2010-02-12 20:20:45
|
Hi Hilmar, -----Mensagem original----- De: Hilmar Lapp [mailto:hl...@ne...] > If the alignment isn't concatenated with sequences from multiple > specimens, couldn't (in fact, shouldn't) you attach the lat/long to > the OTU, though? I.e., where do you attach the specimen currently, and > it do you attach lat/long in a different fashion than the specimen? If I understood well the problem... CDAO presents an OTU annotation concept, and users can instantiate it with any desirable information about the specimen, such as lat/long. One can also develop and inherit other ontologies into CDAO to provide more sophisticated concepts for specific applications and annotations. > CDAOers: what are status and plans for describing the parts of an > alignment right now, and is there support, current or planned, for > partitions / segments of an alignment? Current CDAO version has already incorporated Julie's Multiple Alignment Ontology (MAO; Thompson et al., 2005). MAO presents concepts such as "domain" and "subalignment", I suppose they can be used in this context. Ciao, Francisco -- Prof. Francisco Prosdocimi, PhD ----------------------------- Programa de Pós-Graduação em Ciências Genômicas e Biotecnologia Universidade Católica de Brasília - UCB SGAN 916 Módulo B, Bloco C Sala 213 70.790-160 - Brasília / DF - Brasil Fone: +55 61 34487173 http://biotec.icb.ufmg.br/chicopros |
From: Hilmar L. <hl...@ne...> - 2010-02-12 16:27:59
|
On Feb 12, 2010, at 10:48 AM, Vladimir Gapeyev wrote: > Bill suggested explicitly specifying btree indexes -- I'll go with > that (rather than Pg default, whatever it is), unless someone > suggests otherwise. Please don't do this. The default is btree anyway, and we should not bother with restating it. My suggestion is to specify the type of index (such as bitmap or rtree) only when we have reason to believe that whatever Pg has as the default might not work well here. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Vladimir G. <vla...@du...> - 2010-02-12 15:48:20
|
I am going to set up the schema patching workflow and test-run it to create indexes and a couple more changes. Let me know if there are any concerns. The two minor changes are * Drop geospot_id_sequence -- there is no corresponding table * Correct PK name in stepmatrixelement and create stepmatrixelement_id_sequence As for the indexes, Bill has suggested these lately: Table Field -------- ------- taxon name taxonvariant fullname taxonlabel taxonlabel citation title citation abstract person lastname" phylotreenode taxonlabel_id, phylotree_id Bill suggested explicitly specifying btree indexes -- I'll go with that (rather than Pg default, whatever it is), unless someone suggests otherwise. --VG |
From: Vladimir G. <vla...@du...> - 2010-02-12 14:57:30
|
On Feb 12, 2010, at 3:02 AM, Rutger Vos wrote: > This hasn't been fixed yet: mesquite can't be found, the > mesquite.folder_dir property is set to "null/foo" at runtime. I assume > this is due to the new JNDI configuration system, so the path needs to > be set either in web.xml or treebase-web.xml. Vladimir, can you please > explain how this is supposed to work and put it on the wiki? Jon said he fixed the problem, on treebase-dev:80, Thu afternoon; file uploads work for me as of Fri morning. Details are on the wiki at https://sourceforge.net/apps/mediawiki/treebase/index.php?title=Deployment_by_a_sysadmin . If your local or 6666 deployment relies on the WAR-supplied context.xml, you'd need to update it according to the updated treebase-web/src/main/webapp/META-INF/context.xml.example. As you are into the mesquite matters at the moment, I'd like to re- raise the suggestion to drop Mesquite code from SVN (see the forward below). --VG Begin forwarded message: > From: Vladimir Gapeyev <vla...@du...> > Date: February 7, 2010 4:41:35 PM EST > To: TreeBASE Developers <Tre...@li...> > Subject: [Treebase-devel] Get rid of treebase--core/lib ? > > After the re-configuration of server-side access to Mesquite, is there > any remaining need for the Mesquite unpacked under treebase-core/ > lib? My builds appear to be fine both under 'mvn package' and under > Eclipse. > > I'd then suggest removing this Mesquite code from SVN. And, as we are > up for that, would it make sense to clear the whole lib directory? > I.e., is there anything important there? DB2 drivers in lib/ibm are > useless now. What about lib/jars? > > --Vladimir |
From: Hilmar L. <hl...@ne...> - 2010-02-12 14:39:11
|
(cross-posting to cdao re: alignment partitions) On Feb 11, 2010, at 11:49 PM, Rutger Vos wrote: > I have added lat/lon as semantic annotations on individual cells > using DwC:DecimalLatitude and DwC:DecimalLongitude. [...] > > Conceivably, verbosity could be reduced by attaching the annotations > on <seq> elements instead, but i) although multiple <seq> elements are > allowed "in principle", I don't think any of our tools actually > support this; ii) cdao has no concept of row segments, so the > annotations would be lost if we transformed to nexml to rdf. If the alignment isn't concatenated with sequences from multiple specimens, couldn't (in fact, shouldn't) you attach the lat/long to the OTU, though? I.e., where do you attach the specimen currently, and it do you attach lat/long in a different fashion than the specimen? CDAOers: what are status and plans for describing the parts of an alignment right now, and is there support, current or planned, for partitions / segments of an alignment? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Rutger V. <rut...@gm...> - 2010-02-12 08:02:17
|
This hasn't been fixed yet: mesquite can't be found, the mesquite.folder_dir property is set to "null/foo" at runtime. I assume this is due to the new JNDI configuration system, so the path needs to be set either in web.xml or treebase-web.xml. Vladimir, can you please explain how this is supposed to work and put it on the wiki? On Thu, Feb 11, 2010 at 1:50 PM, William Piel <wil...@ya...> wrote: > > On Feb 9, 2010, at 4:59 PM, Jon Auman wrote: > >> Bill, >> >> This has been fixed. Mesquite requires that the tomcat startup script export the display > > Hi Jon, > > Thanks for whatever you did... but I still can't seem to upload any nexus files... I get a "File upload summary: No matrices or trees uploaded" message. I'm using the dev instance -- tried it with both the port 80 and port 6666 builds. Is there a particular deployment that I should be testing? (attached is a test file, if you need something to try). > > Bill > > > > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-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: Rutger V. <rut...@gm...> - 2010-02-12 04:49:13
|
Hi all, as per issue 2948080, I have added lat/lon as semantic annotations on individual cells using DwC:DecimalLatitude and DwC:DecimalLongitude. There are presently actually no records at all that have geospatially annotated rowsegments in the database so it's hard to test this. Ryan, do you have any examples, or something specific in mind? Conceivably, verbosity could be reduced by attaching the annotations on <seq> elements instead, but i) although multiple <seq> elements are allowed "in principle", I don't think any of our tools actually support this; ii) cdao has no concept of row segments, so the annotations would be lost if we transformed to nexml to rdf. Rutger |
From: Hilmar L. <hl...@dr...> - 2010-02-11 17:52:20
|
Iat/long is clearly metadata. -hilmar Sent from away On Feb 11, 2010, at 9:48 AM, "SourceForge.net" <no...@so...> wrote: > Bugs item #2948080, was opened at 2010-02-08 21:18 > Message generated for change (Comment added) made by rvos > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=1126676&aid=2948080&group_id=248804 > > Please note that this message will contain a full copy of the > comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: internals > Group: None > Status: Open > Priority: 5 > Private: No > Submitted By: Ryan Scherle (rscherle) >> Assigned to: Rutger Vos (rvos) > Summary: Make lat/lon available in nexml > > Initial Comment: > Check whether lat/lon information is available in nexml records > exported from TreeBASE. If not, add it. > > ---------------------------------------------------------------------- > >> Comment By: Rutger Vos (rvos) > Date: 2010-02-11 14:48 > > Message: > The lat/long information is currently not available in the NeXML > serialization. How would we best add this? Would you say that in this > instance it's metadata (i.e. presumably requiring a semantic > annotation, > perhaps using DarwinCore predicates) or data (requiring a lat/long > datatype > in core NeXML, perhaps). I think it's the former, what do you think? > > ---------------------------------------------------------------------- > > Comment By: Rutger Vos (rvos) > Date: 2010-02-11 14:48 > > Message: > Thanks for reporting this bug. We'll look into it as soon as > possible. > > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=1126676&aid=2948080&group_id=248804 > > --- > --- > --- > --------------------------------------------------------------------- > SOLARIS 10 is the OS for Data Centers - provides features such as > DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Treebase-guts mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-guts |
From: Jon A. v. R. <he...@ne...> - 2010-02-11 17:32:20
|
Bill, OK. I fixed it (again). There are two things that need to be set for mesquite to work: 1)Add this to the Tomcat startup script: # Headless mesquite needs a window server (a virtual one is OK) export DISPLAY=localhost:1.0 2) Add this to the CATALINA_HOME/conf/Catalina/localhost/treebase-web.xml file: <Environment name="tb2/MesquiteFolder" value="/home/treebasedev/mesquite- 2.01.tb" type="java.lang.String" override="false" description="Absolute path to the directory where headless Mesquite is unpacked on the host system."/> I had changed the path for treebasedev home directory, and forgot to change it in treebase- web.xml. It's in my notes now and I'll make sure its gets entered in the treebase wiki at Sourceforge. BTW, the output form uploading the test file you sent me yesterday is: File upload summary: One matrix uploaded One tree uploaded The Parser Log: Reading NEXUS file testfile.nex Reading special block: DATA Reading block: CODONS Reading block: TREES Reading block: ASSUMPTIONS Reading block: Mesquite NOTICE null ************************* The current release version of Mesquite is 2.72 build 527 (the version you have installed is 2.01). The latest version is downloadable at: http://mesquiteproject.org/mesquite/download/download.html ************************* File reading complete (file testfile.nex) -Jon On Thu Feb 11 04:55:15 2010, wil...@ya... wrote: > > On Feb 9, 2010, at 4:59 PM, Jon Auman wrote: > > > Bill, > > > > This has been fixed. Mesquite requires that the tomcat startup > script export the display > > Hi Jon, > > Thanks for whatever you did... but I still can't seem to upload any > nexus files... I get a "File upload summary: No matrices or trees > uploaded" message. I'm using the dev instance -- tried it with > both the port 80 and port 6666 builds. Is there a particular > deployment that I should be testing? (attached is a test file, if > you need something to try). > > Bill > > > -- Jon Auman NESCent, Systems Administrator jon...@ne... 919-627-2708 For more info: Ticket <URL: https://help.nescent.org/Ticket/Display.html?id=7349 > |
From: William P. <wil...@ya...> - 2010-02-11 04:50:26
|
On Feb 9, 2010, at 4:59 PM, Jon Auman wrote: > Bill, > > This has been fixed. Mesquite requires that the tomcat startup script export the display Hi Jon, Thanks for whatever you did... but I still can't seem to upload any nexus files... I get a "File upload summary: No matrices or trees uploaded" message. I'm using the dev instance -- tried it with both the port 80 and port 6666 builds. Is there a particular deployment that I should be testing? (attached is a test file, if you need something to try). Bill |
From: Val T. <va...@ci...> - 2010-02-10 22:03:49
|
There are provisions in the data model for such matrices and therefore there is some (mostly skeletal) code. This might be useful sometime in the future if a need to accept continuous chars is identified. Val On Feb 10, 2010, at 4:35 PM, William Piel wrote: > > On Feb 10, 2010, at 4:11 PM, Vladimir Gapeyev wrote: > >> I see code in the migration tools for handling "continuous" vs >> "discrete" matrices, in particular ContinuousMatrixJDBC.java vs >> DiscreteMatricJDBC.java. I'd like to identify a few continuous >> matrices in the data for testing purposes. I thought about looking at >> the values of the "data_type" field in Dump.txt, but the ones see, >> 'Nucleic Acid', 'Amino Acid', 'Morphological', and 'Restriction Site' >> all are discrete in my mind. > > Yeah - none of the migrated datasets contain continuous characters. > > bp > > > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel |
From: William P. <wil...@ya...> - 2010-02-10 21:36:05
|
On Feb 10, 2010, at 4:11 PM, Vladimir Gapeyev wrote: > I see code in the migration tools for handling "continuous" vs > "discrete" matrices, in particular ContinuousMatrixJDBC.java vs > DiscreteMatricJDBC.java. I'd like to identify a few continuous > matrices in the data for testing purposes. I thought about looking at > the values of the "data_type" field in Dump.txt, but the ones see, > 'Nucleic Acid', 'Amino Acid', 'Morphological', and 'Restriction Site' > all are discrete in my mind. Yeah - none of the migrated datasets contain continuous characters. bp |
From: Hilmar L. <hl...@ne...> - 2010-02-10 21:29:36
|
TreeBASE1 does not support continuous characters, so you're not going to find any there. At least that's my understanding. -hilmar On Feb 10, 2010, at 4:11 PM, Vladimir Gapeyev wrote: > Bill, > > I see code in the migration tools for handling "continuous" vs > "discrete" matrices, in particular ContinuousMatrixJDBC.java vs > DiscreteMatricJDBC.java. I'd like to identify a few continuous > matrices in the data for testing purposes. I thought about looking at > the values of the "data_type" field in Dump.txt, but the ones see, > 'Nucleic Acid', 'Amino Acid', 'Morphological', and 'Restriction Site' > all are discrete in my mind. > Thanks, > --vg > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as > DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Vladimir G. <vla...@du...> - 2010-02-10 21:11:27
|
Bill, I see code in the migration tools for handling "continuous" vs "discrete" matrices, in particular ContinuousMatrixJDBC.java vs DiscreteMatricJDBC.java. I'd like to identify a few continuous matrices in the data for testing purposes. I thought about looking at the values of the "data_type" field in Dump.txt, but the ones see, 'Nucleic Acid', 'Amino Acid', 'Morphological', and 'Restriction Site' all are discrete in my mind. Thanks, --vg |
From: Jon A. <jon...@ne...> - 2010-02-09 21:59:58
|
Bill, This has been fixed. Mesquite requires that the tomcat startup script export the display # Headless mesquite needs a window server (a virtual one is OK) export DISPLAY=localhost:1.0 -Jon On Feb 9, 2010, at 9:54 AM, William Piel wrote: > Hi all, > > 1. Uploading a file with a character and/or tree block results in the message "No matrices or trees uploaded" (so no error stack, just fails to import these objects). I thought we had the Mesquite parser working on dev, just not on stage? At any rate, we cannot effectively test for bugs if we cannot do this basic operation. Can we make this a high priority fix? (or if the port 666 version were returned, I could test for bugs on that one). > > 2. Youjun has been relying on Rutger to trigger each build on dev. We need to either give Youjun the power to do this or have someone at NESCent available to do this. > > Bill > > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel ------------------------------------------------------- Jon Auman Systems Administrator National Evolutionary Synthesis Center Duke University http:www.nescent.org jon...@ne... ------------------------------------------------------ |
From: Vladimir G. <vla...@du...> - 2010-02-09 16:50:18
|
On Feb 9, 2010, at 9:54 AM, William Piel wrote: > 1. Uploading a file with a character and/or tree block results in > the message "No matrices or trees uploaded" (so no error stack, just > fails to import these objects). I thought we had the Mesquite parser > working on dev, just not on stage? My apologies for this. Jon and I finished the day yesterday happy that we made it work, but apparently something happened since then. I am checking if the problem might be in the WAR and asking Jon to check the servers. > > 2. Youjun has been relying on Rutger to trigger each build on dev. > We need to either give Youjun the power to do this or have someone > at NESCent available to do this. The current arrangement for redeployment is that I build a new treebase-web.war, commit it to a special repository, and send a request to Jon via he...@ne... to redeploy (usually just on treebasedev). Youjun could do the same, I think. The repository for WARs is svn+ssh://USE...@sv.../repos/ treebase (Youjun would need an account for the NESCent file server.) I am not happy with the amount of interaction and manual work in this process, but that's what we'll have to live with till well after the release. Alternatively, if you'd like to have faster turnaround, you cold set up a web front end on a machine over which Youjun has control. We have started a page for sysadmin-oriented installation instructions at http://sourceforge.net/apps/mediawiki/treebase/index.php?title=Deployment_by_a_sysadmin , which would benefit from being tried out. --Vladimir |
From: William P. <wil...@ya...> - 2010-02-09 15:30:42
|
On Feb 9, 2010, at 9:54 AM, William Piel wrote: > (or if the port 666 version were returned, I could test for bugs on that one). Sorry -- actually, I meant the 6666 version (and indeed, that one is still live). I just tested it on that version but it has the same error: "No matrices or trees uploaded." This is a new bug that has crept in since last week (when uploads worked on dev). It's pretty critical that we be able to test a full basic use cycle of creating a submission, uploading data, publishing it, searching on it, deleting it, so I'm hopeful that this can be fixed right away. bp |
From: William P. <wil...@ya...> - 2010-02-09 14:55:18
|
Hi all, 1. Uploading a file with a character and/or tree block results in the message "No matrices or trees uploaded" (so no error stack, just fails to import these objects). I thought we had the Mesquite parser working on dev, just not on stage? At any rate, we cannot effectively test for bugs if we cannot do this basic operation. Can we make this a high priority fix? (or if the port 666 version were returned, I could test for bugs on that one). 2. Youjun has been relying on Rutger to trigger each build on dev. We need to either give Youjun the power to do this or have someone at NESCent available to do this. Bill |
From: Hilmar L. <hl...@ne...> - 2010-02-08 20:59:41
|
And can you submit this as a bug on Sf.net please? -hilmar On Feb 8, 2010, at 3:37 PM, Jon Auman wrote: > When I click on 'trees' for a larger dataset such as 'oak' I get > the following query in postgresql: > > select phylotree0_.PHYLOTREE_ID as PHYLOTREE1_60_, > phylotree0_.VERSION as VERSION60_, phylotree0_.TB1_TREEID as > TB3_60_, phylotree0_.BigTree as BigTree60_, phylotree0_.Label as > Label60_, phylotr > e0_.ntax as ntax60_, phylotree0_.NewickString as NewickSt7_60_, > phylotree0_.NexusFileName as NexusFil8_60_, phylotree0_.Published as > Published60_, phylotree0_.ROOTNODE_ID as ROOTNODE12_60_, > phylotree0_.RootedTree as RootedTree60_, phylotree0_.STUDY_ID as > TUDY13_60_, phylotree0_.Title as Title60_, > phylotree0_.TREEATTRIBUTE_ID as TREEATT14_60_, > phylotree0_.TREEBLOCK_ID as TREEBLOCK15_60_, phylotree0_.TREEKIND_ID > as TREEKIND16_60_, phylotree0_.TREEQUALITY_ID as TREEQUA17_60_, > phylotree0_.TREETYPE_ID as TREET > PE18_60_ from PHYLOTREE phylotree0_, TAXONLABEL taxonlabel1_, > TAXONVARIANT taxonvaria6_ where > taxonlabel1_.TAXONVARIANT_ID=taxonvaria6_.TAXONVARIANT_ID and > (taxonlabel1_.TAXONLABEL_ID in (select taxonlabel5_.TAXONLABEL_ID > from TREEBLOCK treeblock2_ inner > oin TaxonLabelSET taxonlabel3_ on > treeblock2_.TAXONLABELSET_ID=taxonlabel3_.TaxonLabelSET_ID, > TaxonLabelSET_TaxonLabel taxonlabel4_, TAXONLABEL taxonlabel5_ where > phylotree0_.TREEBLOCK_ID=treeblock2_.TREEBLOCK_ID and > taxonlabel3_.TaxonLabelSET_ID=taxonlab > l4_.TaxonLabelSET_ID and > taxonlabel4_.TaxonLabel_ID=taxonlabel5_.TAXONLABEL_ID)) and > taxonvaria6_.TAXON_ID=$1 > > > Look at the tail end of the query > TAXON_ID=$1 > Can that be right ??? > > I pulled this query directly off the postgresql server from the > command line. The query hangs and never finishes, even if I let it > run for hours. > > It seems to me to be an application error, and not necessarily a > need for indexes specifically. > > -Jon > > ------------------------------------------------------- > Jon Auman > Systems Administrator > National Evolutionary Synthesis Center > Duke University > http:www.nescent.org > jon...@ne... > ------------------------------------------------------ > > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term > contracts > Personal 24x7 support from experience hosting pros just a phone call > away. > http://p.sf.net/sfu/theplanet-com_______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
From: Hilmar L. <hl...@ne...> - 2010-02-08 20:59:16
|
On Feb 8, 2010, at 3:37 PM, Jon Auman wrote: > Look at the tail end of the query > TAXON_ID=$1 > Can that be right ??? Yes. $1 is a parameter placeholder. If PostgreSQL were really trying to parse $1 as the literal SQL, it would generate a parse error. If the query runs excessively long, it's an indication for a missing index or a query execution plan that is poor for some other reason. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |