Hi Christopher, Tomasz:<br><br>I since learned that the MonitorReceiverContents is actually part of the current Kepler trunk.<br>It only wasn't searchable. Now that's also solved (thanks Sean!)<br><br>Tomasz:<br>It sounds what you really need though is a way to query a database that keeps track of state.<br>
Maybe the provenance recorder could help you...<br><br>Bertram<br><br><div class="gmail_quote">On Wed, Mar 17, 2010 at 3:26 PM, Christopher Brooks <span dir="ltr"><<a href="mailto:cxh@eecs.berkeley.edu">cxh@eecs.berkeley.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Tomasz,<br>
<br>
MonitorReceiverContents is an Attribute, not an actor, and it is in<br>
the Kepler svn devel tree.<br>
<br>
<br>
<a href="http://ptolemy.berkeley.edu/ptolemyII/ptIIfaq.htm#kepler" target="_blank">http://ptolemy.berkeley.edu/ptolemyII/ptIIfaq.htm#kepler</a> says:<br>
--start--<br>
Concerning using Ptolemy actors within Kepler, Norbert Podhorszki writes:<br>
<br>
If you find a Ptolemy actor useful, just remember its class name (e.g. ptolemy.actor.lib.Ramp). In Kepler, "Tools/Instantiate Component" menu allows you to type in the class name, which will put an actor instance on your canvas just as dragging one from the actor tree.<br>
<br>
The ptolemy jar is stored in the kepler.jar, so you have access to any Ptolemy actors and directors.<br>
<br>
If you want to use a director not in Kepler tree, you have to use the "Tools/Instantiate Attribute" menu. I use it to get a DDF director frequently (class ptolemy.domains.ddf.kernel.DDFDirector).<br>
<br>
I suppose, you can create a kar file for any ptolemy actor just as for kepler actors, if you want to add some of them into the Kepler actor tree.<br>
--end--<br>
<br>
In a version of Kepler checked out from the svn tree, I did:<br>
Tools->Instantiate Attribute<br>
and entered<br>
ptolemy.vergil.actor.lib.MonitorReceiverContents<br>
and that created an attribute.<br>
<br>
I then ran the model and the ports had information displayed on them.<br>
<br>
Note that the attribute was rendered strangely, it looked kind of squashed.<br>
I'm not sure why.<br>
<br>
_Christopher<div><div></div><div class="h5"><br>
<br>
On 3/17/10 2:49 PM, Tomasz Żok wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Edward and Bertram,<br>
<br>
Thank you for pointing out the possible approaches.<br>
<br>
I have tried the "Listen to director" method some time ago. As far as I<br>
can remember, the output I got was totally unreadable and unmanagable (I<br>
am creating a big workflow, being executed for as long as few hours... I<br>
was overloaded with information from the director). And I think there<br>
were just information about calling fire() or postfire(), etc. but not a<br>
thing about tokens being received on ports. But I tried this approach in<br>
the past, maybe I'll try again soon.<br>
<br>
As for MonitorReceiverContents, I cannot find it in my Kepler-1.0.0<br>
installation. But as Bertram pointed out, there is no such actor in the<br>
recent checkout.<br>
<br>
And I am using DDF director.<br>
<br>
Thank you, best regards,<br>
Tomek<br>
<br>
On 16-03-2010 at 17:03:52 Bertram Ludaescher <<a href="mailto:ludaesch@ucdavis.edu" target="_blank">ludaesch@ucdavis.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Yes, I'm a fan of MonitorReceiverContents (thanks for implementing it<br>
Edward! :)<br>
It nicely shows the queue contents during execution. It also should show<br>
"left over queue content".<br>
<br>
Edward:<br>
What is the set of domain for which this will (mostly) likely work?<br>
(I'm primarily interested in SDF, DDF, and PN.)<br>
<br>
Also, is it correct to assume that runs that have "left over tokens" are<br>
still "valid" w.r.t. the Kahn semantics?<br>
It would be interesting to define a declarative query or integrity<br>
constraint (to use database parlance) that checks queue contents after<br>
execution. One could then declare certain runs as "incomplete", i.e.,<br>
if not<br>
all queues have been emptied.<br>
<br>
On a related note:<br>
When I do a search for "monitor" in a recent check-out of Kepler, I don't<br>
see 'MonitorReceiverContents'.<br>
<br>
Can we still add it? Maybe as part of a suitable module? Chad, David?<br>
<br>
Bertram<br>
<br>
On Tue, Mar 16, 2010 at 8:49 AM, Edward A. Lee<br>
<<a href="mailto:eal@eecs.berkeley.edu" target="_blank">eal@eecs.berkeley.edu</a>>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I'm not sure about Kepler, but in Ptolemy the Debug menu includes<br>
Listen to Director, which will give you this information. It's<br>
in the friendliest form, however...<br>
<br>
Also, in the Utilities->Analysis menu there is a component<br>
called MonitorReceiverContents. Dragging this into the model will<br>
enable display of data in buffers. This only works for certain<br>
domains, however. I'm not sure which director you are using...<br>
<br>
Edward<br>
<br>
<br>
<br>
On 3/16/10 3:26 AM, Tomasz Żok wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
I have some workflow, I run it and after some time it stops -<br>
"execution<br>
finished". At this exact moment I would like to know, which actors had<br>
tokens on some port, but were unable to fire.<br>
<br>
For instance, an actor named "A" has five input ports. During execution<br>
tokens are fired to four out of these five. The director decides there<br>
is nothing else to be fired and finishes the execution. When this<br>
happens I would just like to know, that: Actor "A" did not fire, but<br>
some of its ports received tokens.<br>
<br>
Is this possible in Kepler? It would greatly enhance the debugging<br>
experience of really big and complicated workflows :)<br>
<br>
Best regards,<br>
Tomek<br>
</blockquote></blockquote></blockquote>
<br>
</blockquote>
<br>
-- <br></div></div><font color="#888888">
Christopher Brooks, PMP University of California<br>
CHESS Executive Director US Mail: 337 Cory Hall<br>
Programmer/Analyst CHESS/Ptolemy/Trust Berkeley, CA 94720-1774<br>
ph: 510.643.9841 fax:510.642.2718 (Office: 545Q Cory)<br>
home: (F-Tu) 707.665.0131 cell: 707.332.0670</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Kepler-users mailing list<br>
<a href="mailto:Kepler-users@kepler-project.org" target="_blank">Kepler-users@kepler-project.org</a><br>
<a href="http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users" target="_blank">http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users</a><br>
</div></div></blockquote></div><br>