Hi Christopher, Tomasz: I since learned that the MonitorReceiverContents is actually part of the current Kepler trunk. It only wasn't searchable. Now that's also solved (thanks Sean!)
Tomasz: It sounds what you really need though is a way to query a database that keeps track of state. Maybe the provenance recorder could help you... Bertram On Wed, Mar 17, 2010 at 3:26 PM, 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 >>>>> >>>> >> > -- > Christopher Brooks, PMP University of California > CHESS Executive Director US Mail: 337 Cory Hall > Programmer/Analyst CHESS/Ptolemy/Trust Berkeley, CA 94720-1774 > ph: 510.643.9841 fax:510.642.2718 (Office: 545Q Cory) > home: (F-Tu) 707.665.0131 cell: 707.332.0670 > > _______________________________________________ > Kepler-users mailing list > Kepler-users at kepler-project.org > http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20100317/260caeaa/attachment-0001.html>
