Ecoinformatics Redmine: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362008-04-16T22:24:21ZEcoinformatics Redmine
Redmine Kepler - Bug #3225 (Resolved): If R is not present, then error message just says "null"https://projects.ecoinformatics.org/ecoinfo/issues/32252008-04-16T22:24:21ZChristopher Brookscxh@eecs.berkeley.edu
<p>If I build Kepler using RELEASE-BRANCH-1-0-0 and ptII using rel-7-0-beta-2<br />from source using:<br />ant full-clean rebuild<br />and then run the Statistical Summary demo that uses R, I get:</p>
<p>java.lang.NullPointerException<br /> at org.ecoinformatics.seek.R.RExpression.fire(RExpression.java:698)<br /> at ptolemy.actor.AtomicActor.iterate(AtomicActor.java:398)<br /> at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:170)<br /> at ptolemy.actor.CompositeActor.fire(CompositeActor.java:400)<br /> at ptolemy.actor.Manager.iterate(Manager.java:688)<br /> at ptolemy.actor.Manager.execute(Manager.java:332)<br /> at ptolemy.actor.Manager.run(Manager.java:1071)<br /> at ptolemy.actor.Manager$3.run(Manager.java:1112)</p> Kepler - Bug #3204 (New): Kepler should have FSM exampleshttps://projects.ecoinformatics.org/ecoinfo/issues/32042008-04-02T21:15:37ZChristopher Brookscxh@eecs.berkeley.edu
<p>Finite State Machines are very powerful, there should<br />be a Kepler-specific scientific workflow that <br />illustrates FSMs.</p> Kepler - Bug #3110 (Resolved): Can't access actors via httphttps://projects.ecoinformatics.org/ecoinfo/issues/31102008-01-30T00:14:16ZChristopher Brookscxh@eecs.berkeley.edu
<p>ptolemy.kernel.util.IllegalActionException: Cannot find class: Waveform<br />Because:<br />-- ptolemy.eecs.berkeley.edu<br />-- XML file not found relative to classpath.<br />-- C:\cxh\src\kepler\http://ptolemy.eecs.berkeley.edu/xml/models/Waveform.xml<br />ptolemy.eecs.berkeley.edu<br /> in file:/C:/cxh/ptII/build/classes/ptolemy/moml/demo/Networked/Networked.xml at line 153 and column 118<br /> at ptolemy.moml.MoMLParser._createEntity(MoMLParser.java:3701)<br /> at ptolemy.moml.MoMLParser.startElement(MoMLParser.java:2379)<br /> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:921)<br /> at com.microstar.xml.XmlParser.parseContent(XmlParser.java:1104)<br /> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:924)<br /> at com.microstar.xml.XmlParser.parseDocument(XmlParser.java:481)<br /> at com.microstar.xml.XmlParser.doParse(XmlParser.java:159)<br /> at com.microstar.xml.XmlParser.parse(XmlParser.java:132)<br /> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1334)<br /> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1292)<br /> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1265)<br /> at ptolemy.actor.gui.PtolemyEffigy$Factory.createEffigy(PtolemyEffigy.java:412)<br /> at ptolemy.actor.gui.EffigyFactory.createEffigy(EffigyFactory.java:209)<br /> at ptolemy.actor.gui.Configuration.openModel(Configuration.java:595)<br /> at ptolemy.actor.gui.Configuration.openModel(Configuration.java:555)<br /> at ptolemy.actor.gui.HTMLViewer.hyperlinkUpdate(HTMLViewer.java:264)<br /> at javax.swing.JEditorPane.fireHyperlinkUpdate(JEditorPane.java:320)<br /> at javax.swing.text.html.HTMLEditorKit$LinkController.activateLink(HTMLEditorKit.java:827)<br /> at javax.swing.text.html.HTMLEditorKit$LinkController.mouseClicked(HTMLEditorKit.java:637)<br /> at java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:212)<br /> at java.awt.Component.processMouseEvent(Component.java:5504)<br /> at javax.swing.JComponent.processMouseEvent(JComponent.java:3135)<br /> at java.awt.Component.processEvent(Component.java:5266)<br /> at java.awt.Container.processEvent(Container.java:1966)<br /> at java.awt.Component.dispatchEventImpl(Component.java:3968)<br /> at java.awt.Container.dispatchEventImpl(Container.java:2024)<br /> at java.awt.Component.dispatchEvent(Component.java:3803)<br /> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)<br /> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3901)<br /> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)<br /> at java.awt.Container.dispatchEventImpl(Container.java:2010)<br /> at java.awt.Window.dispatchEventImpl(Window.java:1778)<br /> at java.awt.Component.dispatchEvent(Component.java:3803)<br /> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)<br /> at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)<br /> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)<br /> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)<br /> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)<br /> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)<br />Caused by: com.microstar.xml.XmlException: -- ptolemy.eecs.berkeley.edu<br />-- XML file not found relative to classpath.<br />-- C:\cxh\src\kepler\http://ptolemy.eecs.berkeley.edu/xml/models/Waveform.xml<br />ptolemy.eecs.berkeley.edu<br /> in file:/C:/cxh/ptII/build/classes/ptolemy/moml/demo/Networked/Networked.xml at line 153 and column 118<br /> at ptolemy.moml.MoMLParser.fileNameToURL(MoMLParser.java:1145)<br /> at ptolemy.moml.MoMLParser._findOrParse(MoMLParser.java:4417)<br /> at ptolemy.moml.MoMLParser._attemptToFindMoMLClass(MoMLParser.java:3498)<br /> at ptolemy.moml.MoMLParser._createEntity(MoMLParser.java:3696)<br /> ... 38 more<br />Caused by: com.microstar.xml.XmlException: -- ptolemy.eecs.berkeley.edu<br />-- XML file not found relative to classpath.<br />-- C:\cxh\src\kepler\http://ptolemy.eecs.berkeley.edu/xml/models/Waveform.xml<br />ptolemy.eecs.berkeley.edu<br /> in file:/C:/cxh/ptII/build/classes/ptolemy/moml/demo/Networked/Networked.xml at line 153 and column 118<br /> at ptolemy.moml.MoMLParser.fileNameToURL(MoMLParser.java:1145)<br /> at ptolemy.moml.MoMLParser._findOrParse(MoMLParser.java:4417)<br /> at ptolemy.moml.MoMLParser._attemptToFindMoMLClass(MoMLParser.java:3498)<br /> at ptolemy.moml.MoMLParser._createEntity(MoMLParser.java:3696)<br /> at ptolemy.moml.MoMLParser.startElement(MoMLParser.java:2379)<br /> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:921)<br /> at com.microstar.xml.XmlParser.parseContent(XmlParser.java:1104)<br /> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:924)<br /> at com.microstar.xml.XmlParser.parseDocument(XmlParser.java:481)<br /> at com.microstar.xml.XmlParser.doParse(XmlParser.java:159)<br /> at com.microstar.xml.XmlParser.parse(XmlParser.java:132)<br /> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1334)<br /> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1292)<br /> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1265)<br /> at ptolemy.actor.gui.PtolemyEffigy$Factory.createEffigy(PtolemyEffigy.java:412)<br /> at ptolemy.actor.gui.EffigyFactory.createEffigy(EffigyFactory.java:209)<br /> at ptolemy.actor.gui.Configuration.openModel(Configuration.java:595)<br /> at ptolemy.actor.gui.Configuration.openModel(Configuration.java:555)<br /> at ptolemy.actor.gui.HTMLViewer.hyperlinkUpdate(HTMLViewer.java:264)<br /> at javax.swing.JEditorPane.fireHyperlinkUpdate(JEditorPane.java:320)<br /> at javax.swing.text.html.HTMLEditorKit$LinkController.activateLink(HTMLEditorKit.java:827)<br /> at javax.swing.text.html.HTMLEditorKit$LinkController.mouseClicked(HTMLEditorKit.java:637)<br /> at java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:212)<br /> at java.awt.Component.processMouseEvent(Component.java:5504)<br /> at javax.swing.JComponent.processMouseEvent(JComponent.java:3135)<br /> at java.awt.Component.processEvent(Component.java:5266)<br /> at java.awt.Container.processEvent(Container.java:1966)<br /> at java.awt.Component.dispatchEventImpl(Component.java:3968)<br /> at java.awt.Container.dispatchEventImpl(Container.java:2024)<br /> at java.awt.Component.dispatchEvent(Component.java:3803)<br /> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)<br /> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3901)<br /> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)<br /> at java.awt.Container.dispatchEventImpl(Container.java:2010)<br /> at java.awt.Window.dispatchEventImpl(Window.java:1778)<br /> at java.awt.Component.dispatchEvent(Component.java:3803)<br /> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)<br /> at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)<br /> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)<br /> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)<br /> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)<br /> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)</p> Kepler - Bug #3108 (Resolved): ENM GARP Baseline 3-Actor GARP - Browser Display demo fails with N...https://projects.ecoinformatics.org/ecoinfo/issues/31082008-01-29T06:25:39ZChristopher Brookscxh@eecs.berkeley.edu
<p>The problems below are probably common knowledge, but I've fixed up<br />the "about:" facility so that it will traverse the demos and try to open<br />them. This makes it much easier to quickly try these out.</p>
<p>The first Ecological Niche Modeling (GARP) Workflow: <br />Baseline 3-Actor GARP -Browser Display demo fails.</p>
<p>This is the first Kepler Demo. . .</p>
<p>ptolemy.kernel.util.NameDuplicationException: Attempt to insert object named "convertTo" into a container that already contains an object with that name.<br /> at ptolemy.kernel.util.NamedList.append(NamedList.java:125)<br /> at ptolemy.kernel.util.NamedObj._addAttribute(NamedObj.java:2054)<br /> at ptolemy.kernel.util.Attribute.setContainer(Attribute.java:383)<br /> at ptolemy.kernel.util.Attribute.<init>(Attribute.java:109)<br /> at ptolemy.kernel.util.Attribute.<init>(Attribute.java:86)<br /> at ptolemy.kernel.util.AbstractSettableAttribute.<init>(AbstractSettableAttribute.java:88)<br /> at ptolemy.kernel.util.StringAttribute.<init>(StringAttribute.java:110)<br /> at sun.reflect.GeneratedConstructorAccessor1.newInstance(Unknown Source)<br /> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)<br /> at java.lang.reflect.Constructor.newInstance(Constructor.java:494)<br /> at ptolemy.moml.MoMLParser._createInstance(MoMLParser.java:3985)<br /> at ptolemy.moml.MoMLParser._handlePropertyElement(MoMLParser.java:5068)<br /> at ptolemy.moml.MoMLParser.startElement(MoMLParser.java:2784)<br /> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:921)<br /> at com.microstar.xml.XmlParser.parseContent(XmlParser.java:1104)<br /> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:924)<br /> at com.microstar.xml.XmlParser.parseContent(XmlParser.java:1104)<br /> at com.microstar.xml.XmlParser.parseElement(XmlParser.java:924)<br /> at com.microstar.xml.XmlParser.parseDocument(XmlParser.java:481)<br /> at com.microstar.xml.XmlParser.doParse(XmlParser.java:159)<br /> at com.microstar.xml.XmlParser.parse(XmlParser.java:132)<br /> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1334)<br /> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1292)<br /> at ptolemy.moml.MoMLParser.parse(MoMLParser.java:1265)<br /> at ptolemy.actor.gui.PtolemyEffigy$Factory.createEffigy(PtolemyEffigy.java:412)<br /> at ptolemy.actor.gui.EffigyFactory.createEffigy(EffigyFactory.java:209)<br /> at ptolemy.actor.gui.Configuration.openModel(Configuration.java:595)<br /> at ptolemy.actor.gui.Configuration.openModel(Configuration.java:555)<br /> at ptolemy.actor.gui.HTMLViewer.hyperlinkUpdate(HTMLViewer.java:264)<br /> at javax.swing.JEditorPane.fireHyperlinkUpdate(JEditorPane.java:320)<br /> at javax.swing.text.html.HTMLEditorKit$LinkController.activateLink(HTMLEditorKit.java:827)<br /> at javax.swing.text.html.HTMLEditorKit$LinkController.mouseClicked(HTMLEditorKit.java:637)<br /> at java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:212)<br /> at java.awt.Component.processMouseEvent(Component.java:5504)<br /> at javax.swing.JComponent.processMouseEvent(JComponent.java:3135)<br /> at java.awt.Component.processEvent(Component.java:5266)<br /> at java.awt.Container.processEvent(Container.java:1966)<br /> at java.awt.Component.dispatchEventImpl(Component.java:3968)<br /> at java.awt.Container.dispatchEventImpl(Container.java:2024)<br /> at java.awt.Component.dispatchEvent(Component.java:3803)<br /> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)<br /> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3901)<br /> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)<br /> at java.awt.Container.dispatchEventImpl(Container.java:2010)<br /> at java.awt.Window.dispatchEventImpl(Window.java:1778)<br /> at java.awt.Component.dispatchEvent(Component.java:3803)<br /> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)<br /> at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)<br /> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)<br /> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)<br /> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)<br /> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)</p>
<p>The third GARP demo, "3. GARP with Occurrence Data from Digir/Ecogrid" <br />also fails:<br />java.io.FileNotFoundException: C:\cxh\src\kepler\workflows\eco\garpModel_ImageJ_withData.xml (The system cannot find the file specified)<br /> at java.io.FileInputStream.open(Native Method)<br /> at java.io.FileInputStream.<init>(FileInputStream.java:106)<br /> at java.io.FileInputStream.<init>(FileInputStream.java:66)<br /> at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)<br /> at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)<br /> at java.net.URL.openStream(URL.java:1007)</p>
<p>There are plenty of other errors as well.</p>
<p>One quick way to check for missing demos is to use the "about:" feature<br />in ptolemyII.<br />To do this:<br />1. Start Kepler with ant run-dev<br />2. Help -> Documentation -> Kepler Introduction for Scientists<br /> -> Ptolemy Introduction -> Copyright<br />3. Select "copyright" in "Other copyrights about this configuration (may take a moment to run)." <br />4. Select "about" in "Other information about this configuration." <br />5. Select " Open the .htm, .html, .xml and .pdf " for the introScientist.htm<br />and introProgrammer.htm files.</p>
<p>It is also possible to check for sizes and centering from the same page.<br />The sizes are set for XGA (1024x768), which is the size laptop that I have<br />and Edward may or may not have.</p> Kepler - Bug #3107 (Resolved): http links don't work: Unsupported file type or connection not sup...https://projects.ecoinformatics.org/ecoinfo/issues/31072008-01-29T05:39:54ZChristopher Brookscxh@eecs.berkeley.edu
<p>Under Java 1.5.0 and Windows XP, if I try to click on a http: link<br />in an html window, I get:</p>
<pre><code>Unsupported file type or connection not supported: <br /> <a class="external" href="http://ptolemy.eecs.berkeley.edu#in_browser">http://ptolemy.eecs.berkeley.edu#in_browser</a></code></pre>
<p>The #in_brower is a hack in the Ptolemy HTML code that says to open<br />the link in the external browser (IE, Firefox etc.)</p>
<p>This error message comes from Configuration.java <br />I believe the problem is that<br /><property name="Web Browser" <br /> class="ptolemy.actor.gui.BrowserTableau$Factory"/><br />in ptolemy/configs/extendedEffigyFactory.xml is not handling the link.</p> Kepler - Bug #3106 (New): Out of memory while opening all demos, is -Xss5m or SVG the problem?https://projects.ecoinformatics.org/ecoinfo/issues/31062008-01-29T04:54:18ZChristopher Brookscxh@eecs.berkeley.edu
<p>I'm marking this as having a target milestone of 1.0.0rc1 because<br />I suspect we should remove -Xss5m from build.xml because it means<br />we cannot open up very many models. Once that is addressed, the<br />milestone should be changed to something later.</p>
<p>Under Windows XP with Java 1.5.0_11, Kepler runs out of memory when opening all the demos whereas Ptolemy does not.</p>
<p>It could be that SVG is the issue, or it could be because Kepler<br />does not do lazy evaluation and thus loads in everything.</p>
<p>To replicate<br />1) Start Kepler with "ant run-dev", which uses -Xmx512m<br />2) Help -> Documentation -> Ptolemy Documentation -> Acknowledgements<br />3) Click on the copyright link at the bottom<br />4) Click on copyrights in<br />"Other copyrights about this configuration (may take a moment to run)." <br />5) Click on about in<br />"Other information about this configuration." <br />6) In the "ptolemy/configs/doc/completeDemosPtinyKepler.htm" line, click on<br /> "Open the .htm, .html, .xml and .pdf "</p>
<p>Roughly 25 windows will open and eventually, we get:</p>
<p>Caused by: java.lang.OutOfMemoryError: unable to create new native thread<br /> at java.lang.Thread.start0(Native Method)</p>
<p>Under Windows, the task manager says we are using 330Mb of memory,</p>
<p>Editing the run-dev entry in build.xml and removing:<br /><jvmarg value="-Xss5m"/><br />means we get to 580Mb in the task manager and then Kepler hangs with the<br />CPU Usage at 99%</p>
<p>java -X says that -Xss<br />-Xss<size> set java thread stack size</p>
<p>Perhaps -Xss should be removed from build.xml?</p>
<p>If I increase the Xmx from 512 to 1024, then the show all demos works,<br />At the end the amount of memory reported by the Task Manager is <br />258Mb, with a max of 608Mb<br />Running the last demo (sr/demo/TrafficLight/TrafficLight.xml) shows<br />this memory usage under Kepler:<br /> [java] 14471 ms. Memory: 968096K Free: 211261K (22%)</p>
<p>In contrast, doing the same thing with Ptolemy (no SVG), the task<br />manager reports 142Mb with a max of 142Mb. Running the same demo<br />reports:<br />6780 ms. Memory: 117172K Free: 24710K (21%)</p> Kepler - Bug #3105 (Resolved): Getting Started link on Welcome Page should lead to demoshttps://projects.ecoinformatics.org/ecoinfo/issues/31052008-01-29T00:19:50ZChristopher Brookscxh@eecs.berkeley.edu
<p>This might be old news, but I'll report it anyway.</p>
<p>When I start up Kepler, the "Welcome" window has a link "Getting Started",<br />which leads to kepler/configs/kepler/introScientists-beta1.htm</p>
<p>introScientists-beta1.htm should have a link to <br />kepler/src/configs/ptolemy/configs/kepler/introScientists.htm<br />or else perhaps the Welcome Window should link directly to introScientists.htm<br />It is important that the demos be easily visble to new users.</p> Kepler - Bug #3103 (Resolved): Building actor documentation from within Kepler failshttps://projects.ecoinformatics.org/ecoinfo/issues/31032008-01-25T00:49:48ZChristopher Brookscxh@eecs.berkeley.edu
<p>If the actor documentation does not exist, then when I select<br />Documentation -> Display, a window comes up that allows me to build<br />the documentation. The build continues along for awhile and then fails with.<br />BUILD FAILED<br />c:\cxh\src\kepler\build.xml:1232: The following error occurred while executing this line:<br />c:\cxh\src\kepler\build.xml:1280: The following error occurred while executing this line:<br />c:\cxh\src\kepler\build.xml:1289: Javadoc failed: java.io.IOException: CreateProcess: "c:\program files\java\jdk1.5.0_11\bin\javadoc.exe" -d c:\cxh\src\kepler-docs\dev\documentationFramework\generatedJavadocs -J-DKEPLER=c:\cxh\src\kepler -classpath c:\cxh\ptII -sourcepath c:\cxh\ptII -doclet doc.doclets.PtDoclet -docletpath c:\cxh\ptII\lib\kepler.jar;c:\cxh\src\kepler;c:\cxh\src\kepler\configs;c:\cxh\src\kepler\lib;c:\cxh\src\kepler\lib\images;c:\cxh\src\kepler\build\kepler-configs.jar;c:\cxh\src\kepler\build\kepler-icons.jar;c:\cxh\ptII\lib\diva.jar;c:\cxh\ptII\lib\jython.jar;c:\cxh\ptII\build\ptolemy-doc.jar;c:\cxh\ptII\build\classes;c:\cxh\ptII\build\src;c:\cxh\ptII\ptolemy\distributed\jini\jar\tools.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\jini-core.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\sun-util.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\reggie.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\jsk-policy.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\jsk-platform.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\start.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\reggie-dl.jâ€</p> Kepler - Bug #2420 (Resolved): Need a 25x25 kepler icon to decorate title barshttps://projects.ecoinformatics.org/ecoinfo/issues/24202006-04-18T02:58:30ZChristopher Brookscxh@eecs.berkeley.edu
<p>Hi Laura,<br />I'm assigning this bug to you because you will either know how to fix it<br />or know who to assign this one to. In<br /><a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343</a> <br />you pointed out that we need a 25x25 Kepler<br />icon. I hacked one up at<br />configs/ptolemy/configs/kepler/KeplerSmallIcon.gif<br />but it is ugly.</p>
<p>BTW - The configuration sets _applicationIcon the a FileParameter.<br />TableauFrame reads the _applicatonIcon parameter of<br />the configuration.</p>
<p>_Christopher</p> Kepler - Bug #2414 (New): Opening a preexisting model should open in a blank viewerhttps://projects.ecoinformatics.org/ecoinfo/issues/24142006-04-13T21:42:32ZChristopher Brookscxh@eecs.berkeley.edu
<p>In "add welcome screen for release 1.0" at<br /><a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343</a></p>
<p>Matthew wrote:</p>
<blockquote>
<p>Now this has been added, here is a very common use case, which seems incorrect<br />(reported by Kevin):</p>
<p>1) User starts kepler - gets blank graph frame, with new welcome screen in front</p>
<p>2) User dismisses welcome screen, and is left with blank graph frame</p>
<p>3) User then does "File->Open" and opens an existing workflow</p>
<p>4) The workflow then opens in a <strong>new</strong> graph frame, leaving the original, empty <br />graph frame on the screen.</p>
<p>Proposed resolution:</p>
<p>BEST: at startup, if user does the above, then the workflow gets opened in the<br /><strong>existing</strong> blank graph frame. Subsequently-opened workflows open up in <strong>new</strong><br />graph frames, as before</p>
</blockquote>
<blockquote>
<p>INTERIM: if we don't have time to implement the above for this release, then<br />check to see if we are in the above use-case, and if so, close the blank graph<br />frame after the first workflow has been opened</p>
<p>Any other thoughts/comments/ideas?</p>
</blockquote>
<p>I wrote:</p>
<blockquote>
<p>Probably File Open should be smart enough to realize that the current window<br />is mostly blank and a candidate for replacement. I'm not sure if<br />this will be very easy. For example, when one does File -> Save As, and<br />uses a new name, a new window appears. We need to handle "Unnamed" models<br />specially. I can take a look at this at some point, but probably not before<br />early March.</p>
</blockquote>
<p>I won't have time before Kepler 1.0, so I'm opening this as a separate <br />enhancement. This new bug has to do with the blank or Unnamed models,<br /><a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343</a><br />has to do with the welcome window.</p> Kepler - Bug #2352 (Resolved): Preferences System needs to be resolvedhttps://projects.ecoinformatics.org/ecoinfo/issues/23522006-02-09T17:51:59ZChristopher Brookscxh@eecs.berkeley.edu
<p>I'm creating a bug for this because<br /><a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343</a><br />"add welcome screen for release 1.0" depends on it.<br />I wrote:</p>
<p>Hi Edward,<br />I'm hacking up the Welcome window and would like to have a way<br />the window so it has a "Please don't show me this dialog again" <br />checkbox and I have some questions about VergilPreferences.</p>
<p>- vergil.VergilPreferences should probably be renamed to<br />PtolemyPreferences and moved to ptolemy.actor.gui so that the<br />actor.gui.WelcomeWindow class can get at it and ptolemy.actor.gui does<br />not depend on vergil.</p>
<p>In fact, getting a preference is a fairly basic task, so this<br />should go in some non-gui base class. If we use plain old java<br />properties, then perhaps we could have a preferences class in<br />ptolemy.util? I'd like to be able to get at preferences without<br />requiring moml.<br />Another preference I'd like to see is a way for the user to adjust<br />how much detail the GraphicalMessageHandler window initially shows.<br />GraphicalMessageHandler is in ptolemy.gui and only imports<br />ptolemy.util, so MoML is not available.</p>
<p>- We need a way to access a global property when we don't have a<br />container. In general, I think the Kepler developers are confused<br />about how we should get a Configuration from anywhere in the code.<br />So, we need a preferenceValue(String preferenceValue) that<br />does not require a context or container and gets the value of<br />the global preference.</p>
<p>Comments?</p>
<p>I've included some email below that has further details</p>
<p>_Christopher</p>
<blockquote>
<p>To: Matthew Brooke <<a class="email" href="mailto:brooke@nceas.ucsb.edu">brooke@nceas.ucsb.edu</a>><br />cc: <a class="email" href="mailto:eal@eecs.berkeley.edu">eal@eecs.berkeley.edu</a><br />From: "Christopher Brooks" <<a class="email" href="mailto:cxh@eecs.berkeley.edu">cxh@eecs.berkeley.edu</a>><br />Subject: Re: [Bug 2343] - add welcome screen for release 1.0<br />In-reply-to: Your message of Fri, 20 Jan 2006 16:28:29 -0800.<br /><<a class="email" href="mailto:43D1802D.3000607@nceas.ucsb.edu">43D1802D.3000607@nceas.ucsb.edu</a>><br />Date: Sat, 21 Jan 2006 18:07:54 -0800<br />Sender: <a class="email" href="mailto:cxh@carson.EECS.Berkeley.EDU">cxh@carson.EECS.Berkeley.EDU</a></p>
<p>I've taken the liberty of ccing Edward here.</p>
<p>Matthew Brook writes:</p>
<blockquote>
<p>Christopher:</p>
<blockquote>
<p>Perhaps Edward's preferences manager<br />(ptolemy.vergil.VergilPreferences) can be used?</p>
</blockquote>
<p>When i started the SVG icon stuff, I needed to access properties files<br />from various parts of the code, and spent a lot of time trying to use<br />ptII's existing configuration.xml, to no avail. I finally figured it<br />just wasn't 'available' for enough of the codebase at runtime, without<br />hard-coding paths in order to re-load it (or maybe I'm just too<br />dumb...).</p>
</blockquote>
<p>Right this is a problem in general. It is not always easy to get<br />at the configuration, you usually need a model that was read in.</p>
<blockquote>
<p>So - I went ahead and used java's built-in<br />resourcebundle/properties classes for storing prefs. This is<br />overkill/inappropriate in some places (for example, many of the settings<br />are not localizable, so do not really need resourcebundle files), but it<br />works marvelously. I guess in the meantime, Edward created the<br />VergilPreferences thing, which I haven't looked at - so now we have a<br />proliferation on our hands... :-(</p>
<p>Anyway - I have put all the ui-related settings in <strong>.properties files in<br />configs/ptolemy/configs/kepler/, and they all have names like:<br />ui</strong>***.properties. The 'main' one is uiSettings.properties.</p>
<p>Up to now, these only contain application settings (ie read-only) rather<br />than user settings - so we still need to create a user-settings file for<br />these read/write props. Is that what VergilPreferences currently does?<br />if it's ultra-simple to use, and easy to get a reference to the props<br />class (say via a static method somewhere) let's use it! If not, then<br />let's use POJ!</p>
<p>m</p>
</blockquote>
<p>Right, VergilPreferences saves its perferences in<br />~/.ptolemyII/VergilPreferences.xml<br />or c:/Documents and Settings/username/ptolemyII/VergilPreferences.xml</p>
<p>I think it is fine to have the ui read only settings in<br />configs/ptolemy/configs/kepler</p>
The primary entry point in VergilPreferences is:<br />/** Check to see whether a preference of the specified name is
<ul>
<li> defined in the specified context, and if it is, return it's value.</li>
<li> Note that if there is an error in the expression for the preference,</li>
<li> then this method will return null and report the error to standard ou\</li>
</ul>
</blockquote>
<p>t.</p>
<blockquote>
<ul>
<li> This is done because we assume the error will normally be caught</li>
<li> before this method is called.</li>
<li> @param context The context for the preference.</li>
<li> @param preferenceName The name of the preference.</li>
<li> @return The value of the preference, or null if it is not set.<br />*/<br />public static Token preferenceValue(NamedObj context, String preferenceNa\</li>
</ul>
</blockquote>
<p>me</p>
<blockquote>
<p>) {</p>
<p>I'm not sure what the context would be for the "Show this dialog at<br />startup". This is sort of a global context.</p>
<p>Perhaps we should extend VergilPreferences to provide a default global<br />context with a static accessor? Also, it would be nice to have<br />a static method that returns a String:<br />public static String preferenceValueAsString(String preferenceName);</p>
<p>Also, I don't see how I add a new preference? (Edward?)</p>
<p>I'm not particularly wedded to using .xml for the global preferences, but<br />using xml makes sense in this context, where we are setting things<br />like Relation size, Link bend radius and Show Parameters, and we want<br />these things to be inherited and overridden in the model hierarchy.</p>
<p>However, there is quite a bit of appeal to using Plain Old Java (POJ)<br />properties, like what we do with ptII/lib/ptII.properties, which<br />is created by configure and contains POJ properties that<br />are merged in by VergilApplication. POJ properties do not<br />require MoMLParser, so they are more useful for codegen runtime<br />and other small footprint programs.</p>
<p>BTW - Perhaps we should use ptII/lib/ptII.properties for global<br />properties and first load ptII/lib/ptII.properties and then load<br />~/.ptolemyII/ptII.properties (if it exists) so we can override these<br />properties.</p>
<p>Anyway, seems like we have lots of properties systems, we should<br />hash something out and use it.</p>
<p>1) We could extend VergilPreferences:<br />- static accessor without a context<br />- static accessor that returns a String<br />- static setter of new Properties (with automagic save?)</p>
<p>2) Hack up ptII.properties<br />- configure sets properties, but we need to make it easy for<br />users to override<br />- static setter of new Properties (with automagic save?)</p>
<p>3) Hack up the Kepler properties system<br />- Make it useful in Ptolemy only</p>
<p>Comments?</p>
<p>_Christopher</p>
</blockquote> Kepler - Bug #2351 (Resolved): Welcome Window Programmer/Scientist docshttps://projects.ecoinformatics.org/ecoinfo/issues/23512006-02-09T17:47:47ZChristopher Brookscxh@eecs.berkeley.edu
<p>The Welcome Window introProgrammer.htm and introScientist.htm documentation in<br />kepler/configs/ptolemy/configs/kepler/<br />needs to be updated.</p> Kepler - Bug #2349 (New): Actors should have preconditions to test for long runshttps://projects.ecoinformatics.org/ecoinfo/issues/23492006-02-07T18:19:21ZChristopher Brookscxh@eecs.berkeley.edu
<p>It would be nice if there was an easy way to for a model to test for<br />trivial problems before getting far down a long run.</p>
<p>One idea would be to have such actors implement an interface that included a<br />method that the director would run.</p>
<p>We should think about why having actors do more testing in preinitialize()<br />will not work here. For example, if we have an FSM model, do all<br />the actors get preinitialize() called right away? What about the Case actor.</p> Kepler - Bug #2344 (Resolved): Duplicate Actors that read directorieshttps://projects.ecoinformatics.org/ecoinfo/issues/23442006-01-26T20:06:47ZChristopher Brookscxh@eecs.berkeley.edu
<p>Dan wrote:</p>
<blockquote>
<p>Does anyone out there know if there is a difference in the basic<br />functionality of the DirectoryListing actor (author Christopher<br />Hylands, Edward A. Lee) and the FileArrayPrinter actor (author Wibke<br />Sudholt). Both seem to do the same thing (extract file lists from a<br />directory); the DirectoryListing actor seems more full featured (works<br />with URLs). Does the FileArrayPrinter do anything the Directory Listing<br />actors does not?</p>
</blockquote>
<p>Ilkay then wrote:</p>
<blockquote>
<p>AFAIK, they are the same in functionality. There might be some<br />differences between the datatypes/structures they output, and it needs<br />to be consolidated.</p>
</blockquote>
<p>Christopher wrote:</p>
<blockquote>
<p>Ptolemy II uses the DirectoryListing actor as part of the run all<br />demos demo that runs in the display case.</p>
<p>This demo is ptolemy/demo/RunDemos.xml<br />The actor is used in ptolemy/demo/RunDemosInNewProcess.xml<br />It is also used in ptolemy/actor/lib/io/demo/FilePortParamter.xml<br />and ptolemy/actor/lib/test/auto/ExecRunDemos.xml<br />and ptolemy/domains/sdf/test/auto/filePortParameter.xml</p>
<p>I'm not particularly wedded to the DirectoryListing actor, we could<br />modify it to better meet Kepler's needs and then either discard<br />FileArrayPrinter or have it call DirectoryListing but not be listed in<br />Kepler's ui. I'd prefer to discard FileArrayPrinter and move on.</p>
<p>It looks like FileArrayPrinter is used in the following models:<br />/home/eecs/cxh/src/kepler/src/org/resurgence/moml/FileListSequencer.xml:<br /><entity name="File Array Printer" <br />class="org.resurgence.actor.FileArrayPrinter"><br />/home/eecs/cxh/src/kepler/src/org/resurgence/moml/MoleculeSelector.xml:<br /><entity name="File Array Printer" <br />class="org.resurgence.actor.FileArrayPrinter"></p>
<p>Perhaps the authors of these models could use DirectoryListing or<br />else tell me how DirectoryListing should change?</p>
<p>Seems like a bug should be filed for this one. I'm tempted<br />to take it, but I'm slightly over committed.</p>
</blockquote>
<p>Wibke wrote:</p>
<blockquote>
<p>Sorry for not answering earlier, since I am the author.</p>
<p>I assume DirectoryListing and FileArrayPrinter probably do similar things (I<br />think I came across their similarity earlier), though I would need to test<br />in detail. There were, however, some reasons I had for doing a "duplicate" <br />here:</p>
<ul>
<li>This was one of my very first actors in Kepler :-) and so I potentially<br />overlooked the other one (I am a domain scientist by training).</li>
</ul>
<ul>
<li>In the workflows where FileArrayPrinter is used, actually I do not need<br />the URL, but the path. The reason for this is that later there is a lot of<br />command-line calls and processing. And I did not want to always do String<br />processing before.</li>
</ul>
<ul>
<li>For the Resurgence workflows it is very important to be able to transform<br />arrays into sequences of tokens and vice-versa. If that is possible with<br />DirectoryListing, there is probably not much sense to keep FileArrayPrinter.<br />However, I remember another discussion about a Resurgence actor (it might<br />have been about file copying/writing or similar) where it actually turned<br />out that two actors do something similarly, but not identically. The reason<br />for this has been that I always have to make sure that the Resurgence actors<br />work in very particular ways with sequences of tokens.</li>
</ul>
<p>Unfortunately, I am heavily loaded by a different project at the moment, so<br />I will need a bit time to check this. But polishing the Resurgence work is<br />anyhow somewhere on my personal to-do list ...</p>
</blockquote>
<p>I propose that FileArrayPrinter not be available in the Kepler UI, but<br />that the source code remain in the tree so that these models can continue<br />to run.</p>
<p>If someone wants to modify DirectoryListing in a backward compatibile manner,<br />I'm all for it.</p> Kepler - 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>