DrawFBP - Subnets and External Ports

[Dale Hurtt]

How are subnets and external ports supposed to work in DrawFBP?
Looking at the generated Network for C# and NoFlo it seems like they
are producing very different code.

Here is the graph.

ReadSomething -> WriteSomething

The subnet/graph for ReadSomething is:

IIP -> A -> B -> [External Port Out]

When I generate the network for ReadSomething, C# shows three
components, A, B, and SUBOUT. When I generate it for NoFlo the
components are A and B. With no OUT for B, I cannot connect it to
anything (without modifying the generated code, of course).

Is the code generator on NoFlo not working, or does this reflect a
limitation of NoFlo? (I cannot find subnets in the NoFlo code, so it
looks like you might have to either use DrawFBP without subnets or
"stitch" the generated code together.)

Thanks in advance.

Dale

[Paul Morrison]

Hi Dale,

I'm away from my machine right now so I can't check it, but I suspect I haven't built the NoFlo subnet facility. Not even sure if Henri has defined that... If someone can send me the spec, I can add it in.

TIA

Paul

Sent from Samsung Galaxy Tab (tm) on Rogers

[Dale Hurtt]

Not sure what the spec would look like (still going through your
book), but here is the section on Subgraphs from NoFlo's README:

### Subgraphs

A NoFlo graph may contain multiple subgraphs, managed by instances of
the `Graph` component. Subgraphs are useful for packaging particular
flows to be used as a "new component" by other flows. This allows
building more advanced functionality by creating reusable graphs of
connected components.

The Graph component loads the graph given to it as a new NoFlo
network, and looks for unattached ports in it. It then exposes these
ports as its own inports or outports. This way a graph containing
subgraphs can easily connect data between the main graph and the
subgraph.

Unattached ports from the subgraph will be available through naming
`ProcessName.port` on the Graph component instance.

Simple example, specifying what file a spreadsheet-parsing subgraph
should run with:

# Load a subgraph as a new process
'examples/spreadsheet/parse.fbp' -> GRAPH Reader(Graph)
# Send the filename to the component (subgraph)
'somefile.xls' -> READ.SOURCE Reader()
# Display the results
Reader() ENTITIZE.OUT -> IN Display(Output)

Thanks,

Dale

[Paul Morrison]

I'll give it a shot when I get a chance!

Regards,

Paul

Sent from Samsung Galaxy Tab (tm) on Rogers

[Paul Morrison]

Hi Dale and Henri,

On 13/05/2012 3:57 PM, Dale Hurtt wrote:
> # Load a subgraph as a new process
> 'examples/spreadsheet/parse.fbp' -> GRAPH Reader(Graph)
> # Send the filename to the component (subgraph)
> 'somefile.xls' -> READ.SOURCE Reader()
> # Display the results
> Reader() ENTITIZE.OUT -> IN Display(Output)

I am not sure I understand this notation - are READ and ENTITIZE nodes
within the Reader subnet? If so, it seems to me that you are exposing
the insides of Reader to its users. You do need a way of mapping
subnet port names to the ports of its internal processes, but this
should not be visible outside the subnet. In Wayne Stevens' notation,
alluded to in previous discussions, we used the => notation, meaning
inside/outside equivalence, rather than an explicit connection, e.g. we
could write something like

'somefile.xls' -> INPUT Reader OUTPUT -> IN Display;

Reader: INPUT => SOURCE Read OUT -> ... -> Entitize OUT => OUTPUT;

and of course DrawFBP follows the same philosophy. Of course, I may
have misunderstood...

[Henri Bergius]

Hi,

On Sun, May 13, 2012 at 8:49 PM, Dale Hurtt <dale...@gmail.com> wrote:
> Is the code generator on NoFlo not working, or does this reflect a
> limitation of NoFlo? (I cannot find subnets in the NoFlo code, so it
> looks like you might have to either use DrawFBP without subnets or
> "stitch" the generated code together.)

The way subnets work in NoFlo is that they are not provided by the
NoFlo network itself, but are instead a feature provided by a "Graph"
component.

When the Graph component loads a NoFlo network (from a JSON or .fbp
file), it goes through the free ports in that graph (unconnected
regular ports, and all ArrayPorts) and exposes those. Because many
components use the same port names (for example, almost all components
have an IN and OUT port), the port names are exposed with a namespace,
so the port IN of node Foo in the subgraph will be exposed as
"FOO.IN".

You can see some of this at work in
https://github.com/IKS/Proggis/blob/master/flows/ReadDeliverables.fbp

It would be nice to make the network definitions more similar between
NoFlo and JavaFBP, so I'm interested in feedback on how this should be
changed.

> Dale

/Henri

--
Henri Bergius
Motorcycle Adventures and Free Software
http://bergie.iki.fi/

Jabber: henri....@gmail.com
Microblogs: @bergie

[Paul Morrison]

On 14/05/2012 4:41 AM, Henri Bergius wrote:
> You can see some of this at work in
> https://github.com/IKS/Proggis/blob/master/flows/ReadDeliverables.fbp

Henri, I'm not sure I knew about this format. :-) The NoFlo format you
wanted generated looks like this:

"processes": {
"_Generate":{ "component" :"com.jpmorrsn.fbp.components.Generate"}
,"Infinite__ Queue":{ "component"
:"com.jpmorrsn.fbp.test.networks.InfiniteQueue"}
,"_Display":{ "component" :"com.jpmorrsn.fbp.components.WriteToConsole"}
},
"connections": [
{ "src": {
"process" :"_Generate",
"port":"OUT"
},"tgt": {
"process" :"Infinite__ Queue",
"port":"IN"}
}

Would the other format be better - it certainly looks simpler! Plus,
you could use something like the => notation I mentioned earlier, which
maps outer names to inner names, preserving the black-boxiness of subnets...

Regards,

Paul

[Henri Bergius]

Hi,

On Mon, May 14, 2012 at 5:52 PM, Paul Morrison <paul.m...@rogers.com> wrote:
> Henri, I'm not sure I knew about this format. :-)  The NoFlo format you
> wanted generated looks like this:

<snip>

> Would the other format be better - it certainly looks simpler!

The .fbp format is great for writing network definitions by hand as it
is very concise. But as the file format for drawn networks, I'm not so
sure, as it doesn't (at least currently) have a way to store X/Y
coordinates on where nodes should be displayed.

In general the JSON format is better when being handled by computers.

> Plus, you could use something like the => notation I mentioned earlier, which maps
> outer names to inner names, preserving the black-boxiness of subnets...

That is a good point, I really want to clean that
SUBCOMPONENTNAME.PORT mess I have now and make composites only expose
selected ports from their internal networks.

> Paul

/Henri

PS. Building quite a lot of business logic with NoFlo right now. Feels good! :-)

[Paul Morrison]

On 15/05/2012 4:19 PM, Henri Bergius wrote:
> I really want to clean that
> SUBCOMPONENTNAME.PORT mess I have now and make composites only expose
> selected ports from their internal networks.

Henri and Dale, Just wanted to say that I will put off generating
anything for subnets in NoFlo until Henri has had a chance to look at
that logic again... Henri, if I understood you correctly, I should stay
with the current NoFlo generator logic...

Dale, I am not sure if you understood what SUBOUT (and SUBIN) are about
- they are described in Chap.7 of the book. It says:

SubIn and SubOut have the ability to use their mother�s input and output
ports respectively. They have to be separate processes as they have to
be independently suspendable. Thus, if the mother had two input data
ports, the subnet would have to have two SUBIN processes to handle them.
Of course, SubIn and SubOut are general-purpose components, so they have
to have the mother�s port names specified to them � this is done using
IIPs.

HTH!

Regards,

Paul

--
http://jpaulmorrison.blogspot.com/