Kepler: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362008-11-13T18:20:53ZEcoinformatics Redmine
Redmine Bug #3669 (Resolved): Tabbed pane interface for holding workflow canvas and additional GUI elementshttps://projects.ecoinformatics.org/ecoinfo/issues/36692008-11-13T18:20:53ZTimothy McPhillipsmcphillips@ecoinformatics.org
<p>A number of new user interface elements are being developed for Kepler. Some of these require considerable screen real estate. For example, I would like to have the option of loading the provenance browser with the trace of each workflow run as soon as it completes (bug 3546), and I'd prefer that this not bring up a new window each time. Similarly, I think the Workflow Run Browser (bug 3655) would be best integrated with the main Kepler GUI (although running the provenance and run browsers standalone would be useful as well). Project workspace, report generation, data management, and process monitoring interfaces have also been proposed and are under development.</p>
<p>I suggest we introduce a tabbed pane interface on the right side of the Kepler GUI to hold all of these new (and future) interface elements. The canvas would go in one pane, the provenance browser in another (if enabled), etc. Kepler modules developed for particular projects could take advantage of this GUI extensibility as well.</p> Bug #3586 (Resolved): COMAD traces should be reproducible when there is limited concurrencyhttps://projects.ecoinformatics.org/ecoinfo/issues/35862008-10-30T20:41:18ZTimothy McPhillipsmcphillips@ecoinformatics.org
<p>The ComadTest actor is roughly the COMAD equivalent of Ptolemy's NonStrictTest. It records the stream of data it receives during a run. In training mode it stores an XML representation (similar to a trace file) of this stream in a parameter value. In test mode it throws an exception if the received stream doesn't match the previously stored value of this parameter.</p>
<p>This works fine currently if the showDetails parameter is set to false, hiding all token and object IDs in the stored XML representation. However, this makes it impossible to verify that the provenance records are correct because the dep attribute is hidden (the value of the dep attribute is a list of the ids of tokens on which a new item depends). However, if the IDs are recorded then the ComadTest actor almost always reports a mismatch because, e.g., the IDs in the dep attribute are not guaranteed to be in a particular order, IDs are assigned asynchronously in different actors, etc.</p>
<p>We do not expect traces for multiple runs of COMAD workflows to be exactly reproducible in general due to concurrency. Each actor runs in its own thread and token IDs are pulled from a common pool. But in a simple, three-actor test workflow (CollectionComposer -> ActorToBeTested -> ComadTest), I believe reproducibility to be both possible and desirable.</p> Bug #3547 (Resolved): CollectionReader actor throws exception when input file contains Metadata o...https://projects.ecoinformatics.org/ecoinfo/issues/35472008-10-22T17:59:33ZTimothy McPhillipsmcphillips@ecoinformatics.org
<p>The CollectionReader actor reads in an XML representation of the input to a COMAD workflow and translates the Collection, Data, Metadata, Parameter elements etc into tokens that serve as input to the rest of a workflow.</p>
<p>A bug has emerged that prevents these input files from containing Metadata or Parameter elements. The exception thrown for a Parameter element is:</p>
<p>java.lang.NullPointerException<br /> at org.kepler.util.AnnotationSet.addMetadata(AnnotationSet.java:195)<br /> at org.kepler.util.CollectionXmlImporter._insertMetadataElement(CollectionXmlImporter.java:423)<br /> at org.kepler.util.CollectionXmlImporter.insertChildElements(CollectionXmlImporter.java:192)<br /> at org.kepler.coactors.CollectionReader._insertTopLevelElements(CollectionReader.java:156)<br /> at org.kepler.coactors.CollectionSource.fire(CollectionSource.java:100)<br /> at ptolemy.actor.process.ProcessThread.run(ProcessThread.java:199)</p> Bug #3196 (Resolved): Find/Change license on gpl/lgpl codehttps://projects.ecoinformatics.org/ecoinfo/issues/31962008-04-02T15:45:51ZChad Berkleyberkley@nceas.ucsb.edu
<p>We need to find any code and/or libraries that currently are using gpl or lgpl as the license and negotiate with the author to change it to BSD. Most of the code is already owned by UC so we can just change it. At least one of the jars will need to be investigated.</p> Bug #3182 (Resolved): check for consistent licensing text in all source fileshttps://projects.ecoinformatics.org/ecoinfo/issues/31822008-03-24T17:18:35ZMatt Jonesjones@nceas.ucsb.edu
<p>Kepler is licensed under the BSD. We need to check that all code is properly licensed this way throughout the release, including all source files. Fix any licensing problems that might arise.</p>
<p>We also need to be sure any included software included in the release can be redistributed under the terms of their license, and that we follow those license terms.</p> Bug #3093 (Resolved): Unit test org.nddp.TestCollectionIOPort does not compilehttps://projects.ecoinformatics.org/ecoinfo/issues/30932008-01-23T00:57:33ZTimothy McPhillipsmcphillips@ecoinformatics.org
<p>The JUnit test org.nddp.TestCollectionIOPort does not compile, and has been renamed to TestCollectionIOPort.javaDISABLED in the repository.</p>
<p>The error message is:</p>
<p>org.nddp.TestCollectionIOPort.ComponentEntity_Local is not abstract and does not override abstract method removeInitializable(ptolemy.actor.Initializable) in ptolemy.actor.Initializable</p>
<p>I will try to fix this tomorrow, 1/23/2008.</p> Bug #3091 (Resolved): Warnings building org.nddp.DataTypeshttps://projects.ecoinformatics.org/ecoinfo/issues/30912008-01-23T00:31:08ZTimothy McPhillipsmcphillips@ecoinformatics.org
<p>Building Kepler yields two warnings with the message, "non-varargs call of varargs method with inexact argument type for last parameter". The offending code is in org.nddp.DataTypes.</p>
<p>I will try to fix this tomorrow, 1/23/2008.</p> Bug #2318 (Resolved): Copyrights and licenses of subpackages need to be handledhttps://projects.ecoinformatics.org/ecoinfo/issues/23182005-12-14T02:41:42ZChristopher Brookscxh@eecs.berkeley.edu
<p>Just so we don't forget, I'm submitting the copyright issue as a bug.</p>
<p>As a proposed feature, I modified the Kepler configuration.xml and<br />added copyright.htm so that Kepler can take advantage of the Ptolemy<br />II about: facility that helps handle copyright issues.</p>
<p>The problem is that packages such as Ptolemy and Kepler include<br />copyrighted software from various sources. Each package has<br />a different copyright that usually must be displayed somewhere<br />in the release.</p>
<p>I hacked up the about:copyright facilty to help handle this. The<br />current implementation is not perfect, but it helps.</p>
<p>Here's how it works.</p>
<p>If a URL starts with "about:", then code in ptolemy.actor.gui<br />specially interprets it.</p>
<p>"about:copyright" creates a page that includes links to some base<br />copyrights, such as the Ptolemy copyright and the Aelfred copyright.<br />It also looks for particular actors and if those actors are found, it<br />includes a link to the appropriate copyright. One issue here is<br />that searching for the actors can take time, the user might notice a lag.</p>
<p>If the configuration includes a property called _applicationCopyrights<br />then that the value of that parameter is assumed to be an array of<br />records of the form
{{actor="dot.separated.actor.class.name", copyright="relative/url/to/copyright.\<br />htm"}...}</p>
<p>So, if the util.ImageJActor actor is present, then going to about:copyright<br />will include a link to the javadoc and also to imagej-copyright.htm<br />imagej-copyright.htm does not currently exist, but usually this file<br />would include the ImageJ jar file copyright.</p>
<p>One issue as that the link to the javadoc defaults to pointing to the<br />Ptolemy website if the documentation cannot be found. We could add<br />yet another parameter that would send this traffic to the Kepler website.<br />I'll do this later.</p>
<p>So, to try this out, update your Kepler tree, run "ant run-dev" <br />and then at the bottom of the intro.htm, follow the<br />"This software is protected by this license." link.</p>
<p>On the Kepler copyright page, follow the link at the bottom:<br />"Kepler is based on Ptolemy II" <br />This will bring you to the about:copyright page.</p>
<p>On other cool feature is at the bottom of the Kepler copyright page<br />is "Other information about this configuration"</p>
<p>This brings up a page that includes a link (about:configuration) to<br />expand the configuration, which is a good way to quickly test for<br />missing classes. For Kepler, this will not expand to include all the<br />actors the way it does under Ptolemy, but it still has value.</p>
<p>There are also links to expand all the .xml files listed in a file.<br />For example, "about:demos#ptolemy/configs/kepler/intro.htm" <br />will expand all the workflows listed on the Kepler splash page.<br />One can then run all the demos.</p>
<p>Also, "about:links#ptolemy/configs/kepler/intro.htm" will open<br />up all the .htm, .pdf and .xml links on the splash page, which<br />is a good way to check documentation.</p>
<p>In both cases, the expansion is only one level deep, but I use it<br />all the time to check releases.</p>
<p>I don't think this is a perfect solution but it can be used to<br />help address the copyright problem. Further refinement would help.<br />What would need to be done is that for each actor that uses a third<br />party jar file we would need to create a web page that includes<br />the copyright. This takes quite a bit of work, but helps ensure<br />that the copyright is actually shipped with the release.</p>
<p>If this utility is not of interest, then feel free to remove<br />the link at the bottom of copyright.htm.</p> Bug #2252 (Resolved): Need to add actors for aligning mulitiple DNA or protein sequenceshttps://projects.ecoinformatics.org/ecoinfo/issues/22522005-11-07T02:33:23ZTimothy McPhillipsmcphillips@ecoinformatics.org
<p>We need to wrap the ClustalW and Gblocks programs in collection-oriented actors.<br /> The aligned sequences output by these actors could then be fed into the actors<br />wrapping the Phylip package and used for inferring phylogenetic trees.</p> Bug #2248 (Resolved): Need to merge corresponding mutable and immutable subclasses of DomainObjecthttps://projects.ecoinformatics.org/ecoinfo/issues/22482005-11-05T22:41:52ZTimothy McPhillipsmcphillips@ecoinformatics.org
<p>In alpha7, complex, domain-specific objects passed between actors in<br />collection-oriented workflows were implemented in mutable and immutable pairs,<br />analogous to Java's StringBuffer and String classes. By convention, only<br />instances of the immutable versions of these class (which could be constructed<br />from instances of the mutable versions) were passed between actors. This<br />approach now appears to be overly complicated.</p>
<p>This issue has been addressed, for now, by adding two methods to the<br />DomainObject interface (and skeletal implementation): setWriteLock() and<br />assertNotWriteLocked(). The former method is called automatically when a<br />DomainObject is added to a collection. By convention, the latter method should<br />be called from all public methods of domain objects that change the state of the<br />instance; a runtime exception is then thrown if setWriteLock() was previously<br />called on that instance.</p>
<p>(The previous approach still may be used in cases where it makes sense.)</p>
<p>So far, the following pairs of classes have been merged:</p>
<p>CharacterMatrix, CharacterMatrixBuffer<br />DistanceMatrix, DistanceMatrixBuffer<br />WeightVector, WeightVectorBuffer<br />ProteinAtom, ProteinAtomBuffer<br />ProteinSequence, ProteinSequenceBuffer</p>
<p>The following pairs of classes still need to be merged:</p>
<p>Tree, TreeBuffer<br />TreeNode, TreeNodeBuffer</p>