[kepler-dev] list of connected ports on a given channel

[Norbert Podhorszki]

Good to have lists where I can send well formulated questions, so I can 
find solutions easier after sending them...

I have found that double iteration with
   Port.linkedRelationList()                  and then on each relation
      Relation.linkedSourcePortList()         in case of input ports
      Relation.linkedDestinationPortList()    in case of output ports

gives me the results I need. At least, for SDF test workflows with opaque 
and transparent ports and multiports and channels with width more than one.
Pretty straightforward, isn't it?

Christopher, I started in IOPort.java three days ago, and the nasty 
miracles with receivers and source code comments like "this is 
surprisingly difficult" and "extremely complicated" may have misled me. 
But actually its getRemoteReceivers() gave me the hints finally.

If any of you think, that the above methods may not work in certain 
models, please, notify me.

Best regards
Norbert

On Mon, 31 Jul 2006, Norbert Podhorszki wrote:

>
> Hi,
> I would like to create the following information for a port:
>
> for each channel of the port
>  list of the directly connected ports of the opposite type (input/output)
>
> Not the remote sources or receivers, but the immediate neighbours.
>
> What I need is to determine, when a port is sending token on channel X, that 
> what ports the token is "going" through (including transparent ports). 
> Similarly, when a token is get()-ed at (an opaque) input port, then which 
> port (immediate neighbour) is it coming from (logically).
>
> Do you have such method already at hand, or an idea, how to create it?
> At least for opaque ports?
> At least a solution that is fine for {SDF,PN,DDF} domains?
> At least a solution where there are no buses only single-wide channels?
>
> Many thanks in advance
> Norbert
>
> PS: I am completely lost in the forest of ports, relations, links and 
> receivers; insides and outsides; the many kinds of lists of entities I can 
> get; and the only logically existing notion of channels (after both studying 
> the design doc and the code).
>
>