[Pipet Devel] Overflow/Loci/GMS collaboration

jarl van katwijk jarl at casema.net
Tue Mar 14 17:32:47 EST 2000

> Unfortunatly, the doc is not totally up-to-date and mostly does not reflect wat
> *could* be done with Overflow.

I know, I've some Cellulair Automata knowledge and overflow seems to be based upon these.
A program based upon the Turing set, iterations and selection can do everything. Wether
this building blocks are fitted for a production environment is something else. I'm not
denying Overflow's way of implementing nodes, but I'm pointing at things outside a
scientific setup. A desktop system must be secure and stable too.

The only limitation I'm proposing is: Only use subnets, do not use seperate Overflow
The overhead this will give is very slim, only 4 dataflow processing cicles. (Sensoring,
piping, subnet-execution and visualising), and believe me: the DFP is gonna be very fast,
I'll write it in assembler I that's what is takes to please you :-)
The wrapping will mostly take place at the authentication moment, which is gonna be once
at load time for a node. After registration nodes are trusted and will be executed without

> Don't confuse node types and data types. Node types just means what the node
> does (FFT, OR, IF, exec, ...). You need them (Though if you want to run an app,
> you can use the "Exec" node). As for the data types, they all derive from a base
> object class, so every node have Objects as inputs and outputs. We use real-time
> type identification in nodes to make sure that the inputs are the right type
> (eg. the FFT node expects its input to be a vector, otherwise it'll throw an
> exception). Out Object type is very similar to Glib's Object, except that we use
> some C++ features to do the reference counting and casting automatically
> (instead of gtk_object_ref or GTK_OBJECT()).

I see. It's probably best that I firstly have a detailed look at the overflow code before
I'll have anymore comments on it.

> When I say fast, I mean that Overflow is capable of running ~50,000 simple nodes
> per second - and that's barely enough for what I do (we're working on making it
> faster). Just a fork or opening a socket is orders of magnitude too slow.

If I may ask: where do you need it for?
maybe it's just too much out of reach to combine with gms's objectives after all :(


More information about the Pipet-Devel mailing list