I am using the latest ptolemy from the head of the CVS. The model that i was using to test it should be attached to the first message i sent out. If you didn't receive the attachment, it can be found here: http://groups.google.com/group/comp.soft-sys.ptolemy/browse_frm/thread/b23a3fea9fe84177?hl=en
As for what i am trying to do... I was trying to see if it would be possible to make a mutation at run time inside of the opaque composite actor without requiring the whole workflow to stop. I was thinking that the opaque composite actor might localize the stopping to occur only inside of the composite actor. As i have been investigating this more, it looks like requestChange() is recursively ran on parent containers. As a result this is bubbled up toward the top container running stopFire() at each composite actor container . So it looks like this may not work. =/ What i am really trying to do is at run time pick an actor(atomic or composite) to be used in a specific location of my workflow. Additionally i need to also ensure that the concurrency from the PN domain is maintained in the composite actors. I have tried the ModelReference and RunCompositeActor from ptolemy.actors.lib.hoc. These work alright, but there are issues such as synchronous token transfers of the input and output ports of these actors that make them infeasible to use with my PN workflows. I am continuing to explore new options, however I am not really sure if my goal here is obtainable... Any thoughts? Nick On Wed, 2006-06-21 at 11:02, Edward A. Lee wrote: > In theory, this should work, but there have been various bugs > around it. Are you using version 5.1? The CVS tree might have > a version in which this works. If you send me a model, I'm happy > to try it. > > However, I have to ask why you would want to do this? There is > no advantage, and in fact, there is a significant cost because > there has to be an extra thread for each port of the opaque > composite whose job it is only to move tokens. Just deleting > the inside director should give you the same semantics, and > slightly more efficient execution. > > Edward > > At 06:12 PM 6/20/2006, Nicholas G. Haasch1 wrote: > >Hello, > > > >I have been recently trying to nest a composite actor that contains a PN > >director inside of a workflow with a PN director. During this an > >exception is thrown: > > > >ptolemy.actor.process.TerminateProcessException: > > at > >ptolemy.domains.pn.kernel.PNQueueReceiver.get(PNQueueReceiver.java:185) > > at ptolemy.actor.process.Branch.transferToken(Branch.java:194) > > at ptolemy.actor.process.Branch.run(Branch.java:161) > > at java.lang.Thread.run(Thread.java:534) > > > > > >Also during this i have noticed that the composite actor is registering > >as a blocked actor to the top level workflow while the composite actor > >still has active threads that are not blocked. The result of this is > >that my workflow is ending early because all threads of the top level > >workflow are blocked. > > > >A did a search through the old threads of this mailing list and > >discovered this: > >http://groups.google.com/group/comp.soft-sys.ptolemy/browse_frm/thread/c6518f53ade268e3/be6a079feb81a5b3?q=PN&rnum=1#be6a079feb81a5b3 > >It seemed to indicate that at that time it was not possible to nest PN > >inside of PN: > > > >I would like to know if it is currently possible to do this type of > >nesting. > > > >I have attached the workflow i am using to test nesting PN. > > > >Thanks, > >Nick > > > >Content-Disposition: attachment; filename=test.xml > >Content-Type: text/xml; name=test.xml; charset= > >Content-Transfer-Encoding: 7bit > > > > ------------ > Edward A. Lee > Professor, Chair of the EE Division, Associate Chair of EECS > 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770 > phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845 > [EMAIL PROTECTED], http://ptolemy.eecs.berkeley.edu/~eal > ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]
