I am beginning to put together a component catalog. Below is a copy
of an entry. Comments are welcome. I hope the format doesn't get
munged.
COMPONENTS
Component ID: X00001
Component label: Gets text from user
Description:
X00001 is a utility that asks the user to enter a line of
text. The request to user line can be supplied when an
instance process is created; if none is provided a default
message is used. Although there are two inports they are
both connected to the same inport response function.
Inports:
ct_trigger: Typically received from program start
ct_next: Typically received from end of task
Outports:
ct_user_text: A line of text entered by user
ct_failed: No text read.
Birth data:
char * request; // Request to user message
State data:
struct gfl_cb cb; // Control block for getfline utility
char * buf; // Buffer space for user entered text
char * request; // The request to user message
I totally agree we need some kind of catalog. This looks C-ish, so I would assume that the underlying FBP engine is C-based. However, it is hard to evaluate these component specs without having some idea of how the engine works... Also, assuming components are black boxes, why do we need state data? Maybe your engine requires this to be visible...? Or is it just to help visualization of the function?
Also, what kind of repository and search engine are you visualizing? Are you thinking of a relational database, or something more text-oriented? There was an IBM product back in the 70s called STAIRS, which would have been perfect :-) It supported a set of structured documents, plus a powerful search facility - I believe it was developed to bring some order to the mass of documents that were developed during the IBM antitrust suit...
> I am beginning to put together a component catalog. Below is a copy > of an entry. Comments are welcome. I hope the format doesn't get > munged.
> COMPONENTS
> Component ID: X00001 > Component label: Gets text from user
> Description: > X00001 is a utility that asks the user to enter a line of > text. The request to user line can be supplied when an > instance process is created; if none is provided a default > message is used. Although there are two inports they are > both connected to the same inport response function.
> Inports: > ct_trigger: Typically received from program start > ct_next: Typically received from end of task > Outports: > ct_user_text: A line of text entered by user > ct_failed: No text read.
> Birth data: > char * request; // Request to user message > State data: > struct gfl_cb cb; // Control block for getfline utility > char * buf; // Buffer space for user entered text > char * request; // The request to user message
I hadn't realized that I was being quite that obscure. Mea culpa. I
opine that catalogs are a goodness. Perhaps we can come up with a
format that is a bit more universal.
Let me see if I can clarify what I am a bit. The engine is C based
with an API. The intent is to make it possible to put other languages
on top of the engine. Processes consist of a prolog (the birth
function), an epilog (the death function), state data specific to the
process, and event handlers (inport response functions). The thought
is that the arrival of data at an inport is an event to be handled by
an event handler. In C it is convenient to use separate functions for
these elements, but they could be wrapped together.
Instead of named ports I use typed connectors. To me a connector is
like a cable; you have fittings on each end and some type of stuff
that the connector handles. If you have processes A and B and you are
sending a message of type x the API connect code looks like
dfe_connect(sigil,A,B,x). In a script the connection might be A--(x)--
>B. That's why the port listings show the type. I have a standard
list of connectors that goes with the catalog of components.
I picture the data flow environment as being a suite of single
threaded complexes (I call them nests) that are loosely coupled by
networking software. The scheduling in a nest uses a single queue of
packaged messages. The scheduler consumes packages from one end,
newly sent messages go to the other end. Individual port queues are
only used when ports are blocked.
The environment is pretty no-looper. As a result I have connection
paths that are essentially signals, i.e., messages that say "do some
more stuff". The end result it that I use more inports and outports.
Birth data corresponds to your IIP's. It's data that is loaded when
the process is initialized. I opine that you use state data without
thinking about it. For example I have a component that reads a line
from a file every time it is tickled. It keeps the file pointer as
state data. Just because something is a black box doesn't mean that
it can't have internal state. On the other hand we might not need to
list the state data.
One other thing. Unlike FBP I load everything dynamically. This
means that there is a top process that loads the code for processes
which in turn loads the code for subsidiary processes, etc. The
engine permits different software structures. What I am doing right
now is setting up a system with multiple programs living in the
environment. A program process initially loads all of the processes
it needs. When the program is activated it activates the code that it
loaded. (Programs can run concurrently, but I'm not working with that
yet.)
I'm not worrying too much about repositories at the moment. User
interfaces and repositories can be swapped in and out as a matter of
convenience. At some point one wants alternative versions of
components. For example, the user interface could be command line
driven, GUI driven, or script driven. My focus at the moment is
building a catalog of simple components that serve as glue.
I hope all of this helps.
On Feb 22, 9:47 pm, Paul Morrison <paul.morri...@rogers.com> wrote:
> I totally agree we need some kind of catalog. This looks C-ish, so I
> would assume that the underlying FBP engine is C-based. However, it is
> hard to evaluate these component specs without having some idea of how
> the engine works... Also, assuming components are black boxes, why do
> we need state data? Maybe your engine requires this to be visible...?
> Or is it just to help visualization of the function?
> Also, what kind of repository and search engine are you visualizing?
> Are you thinking of a relational database, or something more
> text-oriented? There was an IBM product back in the 70s called STAIRS,
> which would have been perfect :-) It supported a set of structured
> documents, plus a powerful search facility - I believe it was developed
> to bring some order to the mass of documents that were developed during
> the IBM antitrust suit...
> On 22/02/2012 12:43 PM, Aristophanes wrote:
> > I am beginning to put together a component catalog. Below is a copy
> > of an entry. Comments are welcome. I hope the format doesn't get
> > munged.
> > COMPONENTS
> > Component ID: X00001
> > Component label: Gets text from user
> > Description:
> > X00001 is a utility that asks the user to enter a line of
> > text. The request to user line can be supplied when an
> > instance process is created; if none is provided a default
> > message is used. Although there are two inports they are
> > both connected to the same inport response function.
> > Inports:
> > ct_trigger: Typically received from program start
> > ct_next: Typically received from end of task
> > Outports:
> > ct_user_text: A line of text entered by user
> > ct_failed: No text read.
> > Birth data:
> > char * request; // Request to user message
> > State data:
> > struct gfl_cb cb; // Control block for getfline utility
> > char * buf; // Buffer space for user entered text
> > char * request; // The request to user message
Thanks for the clarification! I definitely agree that catalogs are a goodness. However, I had a few thoughts, based on my JavaFBP and C#FBP experience, which hopefully will muddy the waters, enrich the soup, or whatever...
In JavaFBP (C#FBP is very similar), components (both elementary and subnet) have annotations that give descriptions, specify some attributes, and give the port names and attributes. These can of course be accessed from outside the components, and we have been using them to do both: a) run-time checking in JavaFBP to make sure that packets being sent or received contain data of permitted classes (a recent addition to JavaFBP), and b) checking in the diagramming tool (DrawFBP) that required ports are connected. I am attaching a sample component attributes display from DrawFBP.
Now the annotations are pure Java, and therefore textual, e.g.
@ComponentDescription("Generates stream of packets under control of a counter") @OutPort(value = "OUT", description = "Generated stream", type = String.class) @InPort(value = "COUNT", description = "Count of packets to be generated", type = String.class)
and so could be stored on a text-based repository, but how do you keep them in step with the values in the code? Does Java have an imbed function? Actually, how do you make sure that programmers keep them up to date - even when they are in the code?
Lastly, DrawFBP is really language-agnostic, even though it is written in Java, so is there a way it can access C# annotations in DLLs?
I'd appreciate getting people's thoughts on this.
PS Just a point about IIPs - in JavaFBP and C#FBP they are thought of as passive, non-triggering, so a component whose only inputs are IIPs is therefore treated as having no input connections, and therefor self-starting. Usually the first thing it will do then is "receive" the IIP(s). JavaFBP and C#FBP have been like that for years - and it seems to work :-)
> I hadn't realized that I was being quite that obscure. Mea culpa. I > opine that catalogs are a goodness. Perhaps we can come up with a > format that is a bit more universal.
> Let me see if I can clarify what I am a bit. The engine is C based > with an API. The intent is to make it possible to put other languages > on top of the engine. Processes consist of a prolog (the birth > function), an epilog (the death function), state data specific to the > process, and event handlers (inport response functions). The thought > is that the arrival of data at an inport is an event to be handled by > an event handler. In C it is convenient to use separate functions for > these elements, but they could be wrapped together.
> Instead of named ports I use typed connectors. To me a connector is > like a cable; you have fittings on each end and some type of stuff > that the connector handles. If you have processes A and B and you are > sending a message of type x the API connect code looks like > dfe_connect(sigil,A,B,x). In a script the connection might be A--(x)-- >> B. That's why the port listings show the type. I have a standard > list of connectors that goes with the catalog of components.
> I picture the data flow environment as being a suite of single > threaded complexes (I call them nests) that are loosely coupled by > networking software. The scheduling in a nest uses a single queue of > packaged messages. The scheduler consumes packages from one end, > newly sent messages go to the other end. Individual port queues are > only used when ports are blocked.
> The environment is pretty no-looper. As a result I have connection > paths that are essentially signals, i.e., messages that say "do some > more stuff". The end result it that I use more inports and outports.
> Birth data corresponds to your IIP's. It's data that is loaded when > the process is initialized. I opine that you use state data without > thinking about it. For example I have a component that reads a line > from a file every time it is tickled. It keeps the file pointer as > state data. Just because something is a black box doesn't mean that > it can't have internal state. On the other hand we might not need to > list the state data.
> One other thing. Unlike FBP I load everything dynamically. This > means that there is a top process that loads the code for processes > which in turn loads the code for subsidiary processes, etc. The > engine permits different software structures. What I am doing right > now is setting up a system with multiple programs living in the > environment. A program process initially loads all of the processes > it needs. When the program is activated it activates the code that it > loaded. (Programs can run concurrently, but I'm not working with that > yet.)
> I'm not worrying too much about repositories at the moment. User > interfaces and repositories can be swapped in and out as a matter of > convenience. At some point one wants alternative versions of > components. For example, the user interface could be command line > driven, GUI driven, or script driven. My focus at the moment is > building a catalog of simple components that serve as glue.
> I hope all of this helps.
> On Feb 22, 9:47 pm, Paul Morrison<paul.morri...@rogers.com> wrote: >> I totally agree we need some kind of catalog. This looks C-ish, so I >> would assume that the underlying FBP engine is C-based. However, it is >> hard to evaluate these component specs without having some idea of how >> the engine works... Also, assuming components are black boxes, why do >> we need state data? Maybe your engine requires this to be visible...? >> Or is it just to help visualization of the function?
>> Also, what kind of repository and search engine are you visualizing? >> Are you thinking of a relational database, or something more >> text-oriented? There was an IBM product back in the 70s called STAIRS, >> which would have been perfect :-) It supported a set of structured >> documents, plus a powerful search facility - I believe it was developed >> to bring some order to the mass of documents that were developed during >> the IBM antitrust suit...
>> On 22/02/2012 12:43 PM, Aristophanes wrote:
>>> I am beginning to put together a component catalog. Below is a copy >>> of an entry. Comments are welcome. I hope the format doesn't get >>> munged. >>> COMPONENTS >>> Component ID: X00001 >>> Component label: Gets text from user >>> Description: >>> X00001 is a utility that asks the user to enter a line of >>> text. The request to user line can be supplied when an >>> instance process is created; if none is provided a default >>> message is used. Although there are two inports they are >>> both connected to the same inport response function. >>> Inports: >>> ct_trigger: Typically received from program start >>> ct_next: Typically received from end of task >>> Outports: >>> ct_user_text: A line of text entered by user >>> ct_failed: No text read. >>> Birth data: >>> char * request; // Request to user message >>> State data: >>> struct gfl_cb cb; // Control block for getfline utility >>> char * buf; // Buffer space for user entered text >>> char * request; // The request to user message >> --http://jpaulmorrison.blogspot.com/
On Feb 23, 10:31 am, Aristophanes <c...@tiac.net> wrote:
> The engine is C based
> with an API. The intent is to make it possible to put other languages
> on top of the engine.
I realized I didn't pick up on this comment, and just wanted to say
that I agree that a tool based on C is the best approach that I know
of for supporting multiple languages (including Domain-Specific
Languages). My preference would be to extend the C-based
implementation that I upgraded to fibres recently, and then move on to
use a multithreading tool, such as Boost... but if your nucleus is
extensible, by all means let's go with that! The big problem IMO is
that the "bytecode" languages have painted themselves into a corner!
On Feb 22, 9:47 pm, Paul Morrison <paul.morri...@rogers.com> wrote:
[snip]
> Also, what kind of repository and search engine are you visualizing?
> Are you thinking of a relational database, or something more
> text-oriented? There was an IBM product back in the 70s called STAIRS,
> which would have been perfect :-) It supported a set of structured
> documents, plus a powerful search facility - I believe it was developed
> to bring some order to the mass of documents that were developed during
> the IBM antitrust suit...
I should have paid more attention to your repository question. There
are two repositories in question, one for the catalog, and one for the
components. Right now I'm putting the catalog in a text file which is
okay for a small number of components. One idea I had was to put it
in a web file(s) with a top level one-line-each directory of
components. Click on a line and you get the full description. Use
the web search facilities.
Another idea is to tie it to the IDE. Instead of putting unlabelled
boxes up, have a drop down menu that lists components. Click on a
component and the correctly labelled box goes on the canvas. Also
have the labelled ports sticking on the box when it goes down.
Instead of drawing a line from an outport to an inport, just click on
each one and let the tool draw the connecting line. (I'm a fan of
letting the draw tool do the drawing.)
Side note: If you use connector types as I do, the outport and the
inport have to match by type. Most of the time it suffices to click
on the two boxes; there will only be one legal connection.
Another issue is connecting the catalog (text and visual info) entries
to the components themselves. What kind of repository are the
compiled components in?
I think that all of this argues for using some kind of database as a
repository. In the mean time I'm doing text files. They can always
be converted into something more powerful.
In the case of the catalog repository I assume it is just a matter of deciding on an engine, although, as we have seen, components under different FBP engines have slightly different attributes. Your one-level index would work fine, although in my experience you need to be able to search on the full text as well.
The bigger problem IMO is the component repository, which has got to be highly language- and FBP implementation-dependent, and maybe even IDE-dependent. E.g. In Java (at least Eclipse) we are working with directories of class files. For C# as far as I can see, it's dlls or pdbs. So I am not sure how to manage components in a language-independent way. However, if you are building everything on a C base, I guess everything could be dll-based, although it would be a shame if we had to give up on Java or C# annotations.
Re your IDE idea,we pretty much have that in DrawFBP - if you are working in Java - as you can click on a block, and can navigate through directories of components. Clicking on one of these components will bring up a description and port attributes, so you can try out a number of likely components, checking their descriptions. I just don't show stubs visually to represent ports - that is beyond my artistic capabilities :-) Not to mention the problem of how best to represent array ports. However I would like to stress that IMO this facility is most useful during later stages of design, when you are down to the elementary component level in your design, or are thinking about doing so.
DrawFBP also doesn't have a search facility - which I do feel is essential!
>On Feb 22, 9:47 pm, Paul Morrison <paul.morri...@rogers.com> wrote: >[snip]
>> Also, what kind of repository and search engine are you visualizing? >> Are you thinking of a relational database, or something more >> text-oriented? There was an IBM product back in the 70s called STAIRS, >> which would have been perfect :-) It supported a set of structured >> documents, plus a powerful search facility - I believe it was developed >> to bring some order to the mass of documents that were developed during >> the IBM antitrust suit...
>I should have paid more attention to your repository question. There >are two repositories in question, one for the catalog, and one for the >components. Right now I'm putting the catalog in a text file which is >okay for a small number of components. One idea I had was to put it >in a web file(s) with a top level one-line-each directory of >components. Click on a line and you get the full description. Use >the web search facilities.
>Another idea is to tie it to the IDE. Instead of putting unlabelled >boxes up, have a drop down menu that lists components. Click on a >component and the correctly labelled box goes on the canvas. Also >have the labelled ports sticking on the box when it goes down. >Instead of drawing a line from an outport to an inport, just click on >each one and let the tool draw the connecting line. (I'm a fan of >letting the draw tool do the drawing.)
>Side note: If you use connector types as I do, the outport and the >inport have to match by type. Most of the time it suffices to click >on the two boxes; there will only be one legal connection.
>Another issue is connecting the catalog (text and visual info) entries >to the components themselves. What kind of repository are the >compiled components in?
>I think that all of this argues for using some kind of database as a >repository. In the mean time I'm doing text files. They can always >be converted into something more powerful.
