'From Squeak3.6 of ''6 October 2003'' [latest update: #5429] on 29 June 2004 at 10:53:22 pm'!
#InfoPipe
These old InfoPipes still serve as test-platforms for the Pb* hierarchy.
That is, they are treated as a set of legacy components or otherwise externally-controlled components.
--------------------------------------------------------------------------------------
This is the abstracct superclass for all of the InfoPipe classes.
No instances of this class are ever created. It exists to encapsulate
common state and behavior for its subclasses.
There are three kinds of methods in InfoPipe:
-- abstract methods, whose body is "self subclassResponsibility".
Subclases must define these
-- hook methods, which are given a default implementation in InfoPipe,
but which subclasses are expected to redefine if they want different
behavior. initializePorts is an example.
-- support methods, which we do not anticipate that subclasses will need to override.
Of course, we may be wrong. :-)
apb 2000.4.20
#Buffer
This is the superclass for various kinds of InfoPipe buffers.
What buffers have in common is that they relieve the pressure created by
pumps. That is, a pump connected to the input of a buffer may fill the buffer,
but it will never cause items to flow out of the buffer to the buffer's output. Instead,
the buffer may overflow or continue to fill indefinitely.
If you want to empty a Buffer, connect a Pump to its output, directly or indirectly.
#MergePipe
MergePipe are pipes with multi inports and single outport.
When you push at any inport, an item will be pushed to the outport. When you pull from the outport, it will try to get an item from each inport.
instance variable:
mergeNumber -- the number of inports for this merge pipe
#Pipe
Objects of this class are simple pipes of zero capacity. They can be used to connect
other InfoPipes together. In this simulation, they have zero latency and infinite bandwidth,
so they are not very useful!
#Pump
Pumps provide the 'motive power' for a network of InfoPipes. All of the other
InfoPipe components are passive. Pumps 'pull' items from their inputs, and
'push:' items into their outputs. They may be thought of as 'presurising' the
network. Buffers relieve this pressure.
In addition to a single stroke of the pump, pumps can start a background process
so that they pump continuously. Pumps are parameterized by the interval
between strokes of the pump:
startPumping: strokeIntervalInMilliseconds
The shorter the interval, the faster the rate of flow. The stroke interval
can be changed while the pump is running by sending the message
'strokeInterval: anIntervalinMilliseconds'
#Sink
A Sink is an InfoPipe that catches items that emerge from other infopipes.
So that we can observe what it is catching, this sink keeps a bitBucket that
records the last few items. The size of the bitbucket can be set by sending
the 'capacity: aNumberOfItems' message.
Other refinements of Sink might write the items to files, or display them on the
screen.
#Source
A Source is an InfoPipe that provides other infopipes with items. It has no inport.
#SplitPipe
SplitPipe are pipes with single inport and multi outports.
When you push at the input, an item will be pushed to each outport. When you pull from any outport, it will pull an item from the inport.
instance variable:
splitNubmer -- the number of outports for this split pipe
#MulticastTee
This class was found to add no new behavior from its superclass
#CompoundPipe
A CompoundPipe encapsulates a variable number (> 0) of InfoPipe components. A CompoundPipe is constructed from a set of infopipes that are connected together. From the outside, the CompoundPipe can be treated as a "black box", that is, like a simple InfoPipe component.
This is all very well, except for messages like latency:. What does it mean to set the latency of a CompoundPipe?
instance variables:
components -- an orderedCollection of all the components, might not be needed
activeComponents -- all the pumps in the compound pipe
#PseudoPipe
PseudoPipes exist to associate the ports of a CompoundPipe with the ports of its components.
instance variables:
realPort -- the port of the CompoundPipe this PseduoPipe associated wiht. A PseduoPipe can't be connected to a CompoundPort because the CompoundPort needs to be connected to the input or output of the CompoundPipe.
#InputPseudoPipe
An InputPseudoPipe associates an inport of a CompoundPipe with an inport of its upstream components.
When pushing the inport of the CompoundPipe, it forwards the push message to the InputPseudoPipe, whose outport is connected to the inport of the component.
When pulling the inport of the component, it tryes to pull an item from the outport of the InputPseduoPipe, which forwards the pull message to the inport of the CompoundPipe.
#OutputPseudoPipe
An OutputPseudoPipe associates an outport of a CompoundPipe with an outport of its downstream components.
When pulling the outport of the CompoundPipe, it forwards the pull message to the OutputPseudoPipe, whose inport is connected to the outport of the component.
When pushing the outport of the component, it pushes an item to the inport of the OutputPseduoPipe, which forwards the push message to the outport of the CompoundPipe.
#InfoPipeExamples
Look on the class side for some example InfoPipes.
#InfoPipeTests
This is the root of SUnit tests for InfoPipes.
Not all examples carried along in InfoPipes have been seen to work in 2004: merely failing to work has not lead to their removal.
However many of the examples which readily converted to SUnits tests have been replicated.
This was a totally manual process, and few of the old examples were expunged.
The RBK format could be used to store most of the test setups.
#LimitedSequenceTest
Note to future workers: data streams, like calculations in a physics or mechanics problems, really should carry along dimensions.
It should eb obvious that a Sequence of Strings won't plug in where numbers are expected.
#LimitedStopTest
lst _ LimitedStopTest new.
lst setUp.
lst testStoppingAtLimit
#Mode
The Mode of a port is decided by its owner infopipe. The inport and the outport of a Pump are both Active. The inport and the outport of a Pipe are not fixed but they must be opposite and will be decided when they are connected. Other infopipes have Passive ports.
#InverseMode
An InverseMode is not fixed but it has to be opposite to some VarMode. If its opposite is unified, it is unified.
instance variable:
opposite -- the opposite VarMode of this InverseMode
#Active
An Active Inport calls other infopipes' pull methods.
An Active Outport calls other infopipes' push methods.
#Passive
A Passive inport has a push method ready for other infopipes to call.
A Passive outPort has a pull method ready for other infopipes to call.
#VarMode
A VarMode has to be unified to Active or Passive before it begins to transfer information.
instance variables:
myValue -- if nil, this VarMode hasn't been unified. Otherwise, the Mode it is unified to.
#BoundedBuffer
BoundedBuffer is a buffer of bounded size; the current size can be changed by sending the 'capacity: aNUmberOfItems' message.
The defaultCapacity can be changed in subclasses by overriding the defaultCapacity message.
The behavior should the buffer fill up can be changed by overriding the
'overflow: theExtraItem' message.
#Dropper
An instances of Dropper is a Pipe that may or may not drop the item that is pushed
into it. It has no storage, and so the decision is either to drop the item
or to immediately push it to the sink.
The method 'dropCondition: aPredicate' is used to initialize the drop condition. 'aPredicate'
is a one argument block, which is given the current item as argument, and which should
answer true or false.
The default dropCondition is false.
#DrySwitch
I watch a pump and tell it to stopPumping if it goes dry
This does not always work!
#FileSink
An InfoPipe sink. The items pushed onto this object are writen to the underlying file.
#FileSource
The items for other infopies come from the underlying file.
#Filter
A Filter is an infopoe that can transform the item flowing through it.
instance variable:
function -- the transform function
This class hasn't been completed.
#ReorderingBuffer
Instances of ReorderingBuffer are BoundedBuffers from which items emerge
in pseudo-random order. To observe this effect, it is of course necessary for
the buffer to contain more than one item.
#SequentialSource
A test source that emits strings that look like
'Item 1'
'Item 2'
and so on in a rather boring and predictable sequence.
#LimitedSequence
Represents a limited sequence of Integers
#TopoSort
For making a topological sort of infopipes to place them sensibly on screen.
#Port
This is the superclass of all kinds of ports. Ports are the connectors of infopipes. An infopipe may have multi in ports and multi out ports. A port is associated with a name so it can be identified.
When we say two infopipes are connected, in fact it is the outport of one infopipe is connected to the inport of another infopipe.
instance variables:
owner -- the infopipe that this port belongs to.
connectedTo -- the port that this port connected to.
mode -- a port can have one of these three modes:
Active: the port (actually, the owner of the port) actively requests data from its neighbous
Passive: the port (actually, the owner of the port) passsively wait for its neighbouors requesting data
Var: could be Active or Passive, depnding on how it is connected.
The type system will prevent two ports with the same mode (both are acitve or both are passive) from being connected.
#InPort
These are ports at the input end of an infopipe.
#CompoundInPort
These are ports at the input end of a compound pipe. Each CompoundInPort is corresponding to an inport of an upstream component.
Each Compund inport has two owners: one is the real owner, which is the compound pipe it belongs to; one is the pseudo owner, whick is the psuedo pipe it belongs to. This pseudo pipe directs this port to a component within that compound pipe.
#OpenEnd
This is a special port. It has no owner, no mode, and it is connected to nothing. A port whose owner is not connected to another infopipe is connected to the open end.
This is a singleton class.
Items pushed
out through an open end "drop onto the floor". Attemps to pull from
an open end "suck air" (answer nil).
#OutPort
These are ports at the output end of an infopipe.
#CompoundOutPort
These are ports at the output end of a compound pipe. Each CompoundOutPort is corresponding to an outport of a downstream component.
Each Compund outport has two owners: one is the real owner, which is the compound pipe it belongs to; one is the pseudo owner, whick is the psuedo pipe it belongs to. This pseudo pipe directs this port to a component within that compound pipe.
#PbAAA
This class is a place-holder for this comment and a few hack-methods.
Do this: PbPartMorph readRBKFile
to read in a sample setup
To get a pallette of parts: Flaps newPbConnectorsFlap openInWorld; setToPopOutOnDragOver: false.
Make a document: PbAAA grepComments
#PbConnectorMorph
Adapting Ned's ConnectorMorph system has not been trivial.
Rik had expected this class to be practically an alias.
#PbEdgeMorph
I am the wee border morphs where edge connectors might exist.
#PbInPortMorph
Provide a visible target for a connector.
Assure that underlying model wantsAttachment... or don't light up fo rit.
#PbLineBeginConstraintMorph
That's what we like: a transparent re-use of existing superclasses.
#PbLineFinishConstraintMorph
That's what we like: a transparent re-use of existing superclasses.
#PbOutPortMorph
The active morph that causes the arrow to start drawing.
Assures that underlying model connection is plausible and then that it gets connected.
#PbPartMorph
This is the root of a hierarchy of "Plumber's Helpers" classes, normally named Pb*.
Each represents meta-information about an externally-controlled component (initially, only old InfoPipes are handled) and may be involved in manifesting a network into simulation objects either in software simulation, real software components (possibly networked, possibly on heterogenous hardware), or in hardware components.
The symbol for the element Lead is Pb, from the Latin "Plumbum".
Plumbum is the eponym of "plumbing"
Pb is not a tired 2-letter tag, and simple textual replacement can be done quickly if ever we decide to.
The plan is to stand on Ned's shoulders and use NCConnectors
Other projects (some commercial) have used GFST (once known as GoFigure) for similar purposes.
With acquisition of GF by ParcPlace, now CinCom, those efforts are themselves legacies.
The main differences between existing Pb-subclasses are topology and appearance, although the intent is that each be as knowledgeable as possible about the represented object.
The sample objects (InfoPipes) are pretty similar except for topology.
These meta-objects allow reasoning about the the hard objects without the expense of fabricating a physical network.
Do this: PbPartMorph readRBKFile
to test out file-in capabilities from a human-obtuse input file.
A few samples are provided as files.
#PbBuffer
Also displays the buffer contents.
#PbLambda
An upside-down Wye looks like Lambda. Don't ask a plumber about that 8-)
#PbNWaySplit
All of the output pipes are the same w.r.t. Active/Passive
#PbPump
Includes a control button to turn the pump on/off
#PbTeeE
Tees are capriciously assigned to have one of {in, out}port and two of {out,in}port.
Only two should be needed, since Morphs can be rotated.
#PbVPipe
A stright-through pipe, initially Vertical.
#PbElbow
A stright-through pipe, functionally, but visually bent.
Two of them provides plenty of possibilities with rotation of morphs allowed
#PbFilter
Filters hook up to a hardPipe class that has installable transfer functions.
By request, nee, demand: the RBK language interface can install a block in a given Filter.
#PbWye
A simple 2-1 merge. Real plumbers call this by the letter Y, spelled out as Wye in the hardware store.
#PbNWayMerge
All of the input pipes are the same w.r.t. Active/Passive
#PbMtoN
So generic it's practically useless.
Defaults are that the first port to be hooked up will set the expectations of the rest.