Hi, Thank you for pointing me how to find and use MonitorReceiverContents. It is a great tool to debug workflows and I find it very helpful. It has already done great things for me and for sure will do more in my further works :)
@Christopher: Btw. the attribute renders strangely in my Kepler instance as well. Thank you, best regards, Tomek On 17-03-2010 at 23:26:38 Christopher Brooks <cxh at eecs.berkeley.edu> wrote: > Hi Tomasz, > > MonitorReceiverContents is an Attribute, not an actor, and it is in > the Kepler svn devel tree. > > > http://ptolemy.berkeley.edu/ptolemyII/ptIIfaq.htm#kepler says: > --start-- > Concerning using Ptolemy actors within Kepler, Norbert Podhorszki writes: > > 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. > > The ptolemy jar is stored in the kepler.jar, so you have access to > any Ptolemy actors and directors. > > 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). > > 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. > --end-- > > In a version of Kepler checked out from the svn tree, I did: > Tools->Instantiate Attribute > and entered > ptolemy.vergil.actor.lib.MonitorReceiverContents > and that created an attribute. > > I then ran the model and the ports had information displayed on them. > > Note that the attribute was rendered strangely, it looked kind of > squashed. > I'm not sure why. > > _Christopher > > On 3/17/10 2:49 PM, Tomasz ?ok wrote: >> Hi Edward and Bertram, >> >> Thank you for pointing out the possible approaches. >> >> I have tried the "Listen to director" method some time ago. As far as I >> can remember, the output I got was totally unreadable and unmanagable (I >> am creating a big workflow, being executed for as long as few hours... I >> was overloaded with information from the director). And I think there >> were just information about calling fire() or postfire(), etc. but not a >> thing about tokens being received on ports. But I tried this approach in >> the past, maybe I'll try again soon. >> >> As for MonitorReceiverContents, I cannot find it in my Kepler-1.0.0 >> installation. But as Bertram pointed out, there is no such actor in the >> recent checkout. >> >> And I am using DDF director. >> >> Thank you, best regards, >> Tomek >> >> On 16-03-2010 at 17:03:52 Bertram Ludaescher <ludaesch at ucdavis.edu> >> wrote: >>> Yes, I'm a fan of MonitorReceiverContents (thanks for implementing it >>> Edward! :) >>> It nicely shows the queue contents during execution. It also should >>> show >>> "left over queue content". >>> >>> Edward: >>> What is the set of domain for which this will (mostly) likely work? >>> (I'm primarily interested in SDF, DDF, and PN.) >>> >>> Also, is it correct to assume that runs that have "left over tokens" >>> are >>> still "valid" w.r.t. the Kahn semantics? >>> It would be interesting to define a declarative query or integrity >>> constraint (to use database parlance) that checks queue contents after >>> execution. One could then declare certain runs as "incomplete", i.e., >>> if not >>> all queues have been emptied. >>> >>> On a related note: >>> When I do a search for "monitor" in a recent check-out of Kepler, I >>> don't >>> see 'MonitorReceiverContents'. >>> >>> Can we still add it? Maybe as part of a suitable module? Chad, David? >>> >>> Bertram >>> >>> On Tue, Mar 16, 2010 at 8:49 AM, Edward A. Lee >>> <eal at eecs.berkeley.edu>wrote: >>> >>>> >>>> I'm not sure about Kepler, but in Ptolemy the Debug menu includes >>>> Listen to Director, which will give you this information. It's >>>> in the friendliest form, however... >>>> >>>> Also, in the Utilities->Analysis menu there is a component >>>> called MonitorReceiverContents. Dragging this into the model will >>>> enable display of data in buffers. This only works for certain >>>> domains, however. I'm not sure which director you are using... >>>> >>>> Edward >>>> >>>> >>>> >>>> On 3/16/10 3:26 AM, Tomasz ?ok wrote: >>>> >>>>> Hi, >>>>> >>>>> I have some workflow, I run it and after some time it stops - >>>>> "execution >>>>> finished". At this exact moment I would like to know, which actors >>>>> had >>>>> tokens on some port, but were unable to fire. >>>>> >>>>> For instance, an actor named "A" has five input ports. During >>>>> execution >>>>> tokens are fired to four out of these five. The director decides >>>>> there >>>>> is nothing else to be fired and finishes the execution. When this >>>>> happens I would just like to know, that: Actor "A" did not fire, but >>>>> some of its ports received tokens. >>>>> >>>>> Is this possible in Kepler? It would greatly enhance the debugging >>>>> experience of really big and complicated workflows :) >>>>> >>>>> Best regards, >>>>> Tomek -- Tomasz Zok Poznan Supercomputing and Networking Center ul. Noskowskiego 10, 61-704 Poznan, POLAND http://www.man.poznan.pl
