Hi Tomasz, I submitted a bug about the attribute render problem. This problem occurs with other Attributes that contain text. The problem appears in the Kepler graph editor, but not in a vanilla Ptolemy graph editor. The bug is: http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4903
_Christopher On 3/22/10 6:19 AM, Tomasz ?ok wrote: > 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 > -- 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
