World: r3wp

although GLASS will use the data within AGG instead of view/faces.

Hrm...  Accord to stats my node is still dirty although I KNOW I 
am returning TRUE from purify()

so after 15 years of analysis, design and countless prototypes of 
all shapes and sizes , I am now finally working on the first true 
code that will find itself into some layer of the GLASS engine. 

=oD

you called content on the plug before calling stats?

(content is a duplicate word for the cleanup function)

Yup!

!color/process() [
]
!color/purify() [
]
0.255.75
0.255.75 (should be)
>> c/valve/stats c
liquid/color[1]/stats [
    ================
    PLUG STATISTICS:
    ================
    LABELING:
    ---
    type:      color
    category:      !plug
    serial id: 1

    LINKEAGE:
    ---
    total subordinates: 3
    total observers: 0
    total commits: 0

    VALUE:
    ---
    tuple!: 0.255.75

    INTERNALS:
    ---
    pipe?: none
    stainless?: false
    dirty?: true
    shared-states:
    linked-container?: false
    mud: 1.2.3
    ================
]
>> c/liquid
== 0.255.75
>> content c
!color/process() [
]
!color/purify() [
]
== 0.255.75

i don't know a part from you forgetting to liquify the plug first 
what could be going on!

that's a class... not an instance.

use liquify first.

c: liquify !color

from the liquid code's purify documentation (in the code)


   ; we RETURN if this plug can be considered dirty or not at this point. 

so if you return true, it remains dirty.

I might have described it the other way around, but I meant to say 
like its described in the above sentence... sorry if I mislead you!

LOL, fix blood.r then, please!


; this is ESSENTIAL determines if plug is dirty or not... basically

; if you return false, the node stays dirty... and is re-evaluated 
everytime.
; if you forget to return a value, liquid causes an error. 
true

hahaha

yep... I WILL

Fixed.  Sweet!

strange I can't find that specific code in blood.r... I guess I already 
fixed here, hehe.

darn, even I was using it upside down in many plugs, in other stuff! 
  hehe I guess I should learn to RTFM... especially when I writing 
it!   ;-)

LOL

you guys can't imagine how nice it feels to be discussing and teaching 
about how to use liquid.... I've now got three pupils... in one week... 
that's so cool...

Oh, my bad.  It's not in Blood.r.  It's in the code you posted above 
for the !color node...

Congrats!

anyone who wants to get to use liquid, don't hesitate to try and 
ask stupid questions.  They are hard to answer, and its giving me 
a chance to get a general feeling of what needs more attention in 
the forthcomming revision to the whole liquid documentation.

for the layout algorythm,  I actualy did a complete flow analysis 
of a row/column resizing liquid graph.  its actually rather simple, 
when you force yourself to follow what data goes where.  note that 
I was able to build this without creating a processing cycle... which 
is neat, since some values are going to the parent face and coming 
back to its pane elements.

It's not clear why you created the !int-range-srv plug for Blood.r 
rather than just creating !int-range directly.

when you pipe two or more nodes together (using pipe() on a plug, 
using the /piped refinement of liquify, or fill/pipe) the system 
automatically creates a pipe server which acts as a broker amongst 
all piped plugs.

this is a normal plug to which all plugs are linked, via the pipe? 
attribute.

this allows you to normalize the values amongst all piped nodes. 
 since, you can redefine that plug, like any other.

Ok...  So, what's the difference between a pipe and a link? >;)

to tell the system what node to allocate, you preset the pipe-server-class 
in advance, so it knows what kind of pipe you want.

Yeah, I figured that last part out.

linked nodes will ask their "subordinates" about their values... 
this starts a recursive chain reaction, until all subordinates of 
all subordinates have cleaned up.

but no two values may intercommunicate.

plugs may be filled with data directly.  when you do this the node 
becomes a container, and this effectively turns off all of the linking 
management..

your plug simply stores a value and returns  it (but purify IS still 
called on it)

pipes work in about the same way, but every time a value is filled 
within a piped plug, ALL of the other members of that pipe ALSO get 
filled with the same value.

the pipe server thus serves as an in-between.  the fact that its 
also a plug makes it very flexible, since you can call the purify 
function on it.

(sorry, define the purify function on it)

note that you can LINK the pipe server and set it to a linked-container? 
 too! but that is advanced usage.

linked-containers, accumulate their subordinate data AND add the 
value you filled , as if it where an extra link... which then goes 
through the normal process mechanism.

note that when you fill a pipe server through a node... even that 
node receives the data back.

the pipe server can be used to normalise the data into its purest 
form, and allows many things in your application to interact with 
it as peers.  one can be a string another an int.  but for each pipe 
client, they could care less about who and what the others are.  
they just need to know that, in this case, they are always receiving 
an int, and can convert it back to the format they need.

The computing methods mutation is one of the most powerfull and unique 
aspects of liquid.  the same plug can be used for many different 
purposes, and it can go to-from any method to another.

one important note, is that switching computation modes, NEVER unlinks 
previous subordinates... it will only ignore them.   only the pipe 
aspect is dynamic and can be unlinked automatically by the internal 
plug managers...

btw, when we are working with pipes, we use the attach and detach 
functions instead of link/unlink.

I will start building explicit tutorials this week end.

I know have a pretty good idea of recurring topics.

and strangely, you guys are all pretty much evolving and learning 
in about the same pattern... so I have some clues into how to order 
the tutorials.  :-)

Ok.  I think I'm starting to see what you are doing with pipes.  
Some of the voodoo in Blood.r isn't as mystical as it was a few minutes 
ago. ;-)