[Gridflow-dev] ping (fwd)

[Mathieu Bouchard]

On Sat, 28 Aug 2004, Tom Schouten wrote:

> > > i have one big question actially. is gridflow seperable from pd and ruby?
> > GridFlow is absolutely not separable from neither C++ nor Ruby.
> > That is, unless you want to go back to GridFlow 0.5 (may 2002)...
> ouch. does gridflow rely on ruby's garbage collector? (if there is any,
> sorry don't know nothing bout ruby myself)
> how important is the ruby part?

I'm not too sure, it depends what you count in and what you count out.
Let's say approximately one-third. [@print] and [fps] and [@export_symbol]
and [shunt] are written in Ruby, for example.

> > > maybe i shouldn't quote esr on this (or at all) but i did read his
> > > latest unix book and like the way he presents the 'policy' vs
> > > 'mechanism' thing. that's what it's all about, in the end.
> > I think you are being quite unclear here.
> i'm sorry. more precisely i was talking about this:
> http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877777

I haven't read this book, but I've been aware of the "Policy vs Mechanism"
concept for a long, long time; I think it was mainly in relationship with
Xlib; "Xlib Programming Manual", O'Reilly 1988, mentions this separation
at the very beginning... I think I read another book that insisted much
more on it and elaborated on the how and why, but I can't recall which
book that was.

However I still don't quite get why you mention that at this point in the
conversation. You have something on your mind that you think I can read,
but my telepathic powers don't extend across the ocean.

> > ok, so let's write [#import_pdp] and [#export_pdp]. What packet-types
> > ought to be supported by those two object-classes? I mean a GridFlow Grid
> > should map to how many PDP packet-types, and which ones?
> no, i'd like to keep puredata out of it,

I didn't mention PureData. The currently available [@export] and
[@export_list] and [@export_symbol] and such, work with PureData, jMax, 
and also without either; just like any other GridFlow object.

------------------8<--------cut-here--------8<------------------
require"gridflow"
include GridFlow
x = FObject["@ +"]
y = FObject["@export_list"]
z = FObject.new
def z._0_list(*a) puts a.join"," end
x.connect 0,y,0
y.connect 0,z,0
x.send_in 1, 2,3,5,7
x.send_in 0, 10,20,30,40
------------------8<--------cut-here--------8<------------------

The above code will print: 12,23,35,47

> if possible. i'd like to connect on the c/c++ library level. i.e. just
> a language binding between gridflow and pf, in the way you would
> connect to ruby i presume.

Ruby is not what would be called a "language binding" for
GridFlow. The "language bindings" for GridFlow are towards PureData and
jMax. Ruby is one of the languages that GridFlow itself is written
in. Understood?

gridflow.so is only designed to be interacted with at the Ruby level, but
that doesn't prevent someone from doing that in C++. For example, The
Ruby<->PureData bridge (gridflow.pd_linux) is written in C++. It's just
that it's constantly using both the Ruby API and the PureData API and
translating between the two (ruby floats... pd floats... ruby symbols...
pd symbols... ruby lists... pd lists...)

> > > * then incrementally map functionality, do what you need most first.
> > > this works really well. maybe i'll make it my business one day.
> > I'm trying to make GF my business, but I don't work often enough on it :-/
> obsession seems to be a prerequisite..

I have obsession, but only sporadically.

> i might just pick out the functionality alone..

What do you mean by that?

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju