World: r3wp

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. ;-)

know = now

cool  :-)

the most basic thing to understand about liquid is that the central 
part of any application is not the interface... its the DATA.

notice that the integer range is not applied to the field... its 
applied to the ABILITY.

no matter how you try to set the ability, IT will always be clamped... 
there is no way to break it.

so the field just inherits that behaviour FROM the character WITHOUT 
ANY SINGLE LINE OF CODE it became an integer field.

a subtle but extremely powerfull and explicit demonstration of dataflow 
robustness.

glue now has a plug that returns gfx text size given any value and 
a font  :-)

WTF?!?  How did you do it?  This is EXACTLY what I've been working 
on!

-------------------------------------------------
NOTE:  

FROM NOW ON, 

every usable !plug definition that I post will be in black, to make 
it easy to differentiate from test code, and copy in your own libs.

-------------------------------------------------

	;-     glue-proc-face:
	glue-proc-face: make face [size: 100x100] 

	;-----------------
	;- !gfx-text-area
	;-----------------

 ; this class returns the area which a value, when represented as 
 a string, occupies.
	;
	; returns: a pair representing width and height
	;
	; usage:

 ;  linked only, unlabeled.  (filling this node will permanently freeze 
 it)
	;
	; inputs:
	; (1) [any!] value
	;     the first input is formed to a string, or set to ""
	;   	
	; (2) [object!:font] font to use

 ;     the test will be run with this font, irrelevant of what font 
 is currently set in the face.
	;
	; <TO DO>: add explicit support for /para facet
	;-----------------
	!gfx-text-area: make !plug [
		liquid: 0x0
		
		;-----------------
		;-    frozen?()
		;-----------------
		; plug won't do anything until you have proper linkage done.
		;-----------------
		frozen?: func [
		][
			vin ["" self/valve/type {/frozen?()}]
			vout
			(2 <> length? subordinates)
		]

		valve: make valve [
			;-----------------
			;-    process()
			;-----------------
			process: func [
				plug
				data
			][
				vin ["" self/valve/type {/process()}]
				plug/liquid: 0x0
				glue-proc-face/font: data/2
				glue-proc-face/size: 1000x1000
				glue-proc-face/text: any [
					attempt [to-string data/1]
					""
				]
				plug/liquid: size-text glue-proc-face
				
				vout
			]
			
			
		
		]
	]

Heh.  A bit simpler than the approach I was going to take, that is, 
if it does what you say it does... =D

yep, black text is tested and functional... note the explicit comment 
header

taken strigt out of glue-lib

I think I still don't understand what in particular Liquid is, but 
would it be e.g. good system to do some animation system in? I mean 
- something like Scala. You have some objects, wipes, effects, happening 
at various times, and the might be cross dependant, etc., so that 
when something happens here, something else happens there :-)

Is there a way to hook into the attach function?  I want to build 
a pipe-server that handles multiple values but I want to be able 
to hook up the input plugs in any order and in some cases not have 
a plug for any given value.  To accomplish this I want to create 
a block that tells me which order the plugs are connected in so that 
I can use the index to select the correct plug from the server's 
liquid.

this may be a wild guess, but doesn't the !plug/subordinates do that? 
  I haven't been using pipes so much as links, but I would guess 
you would look at that, and I'd assume the plugs are in the order 
that they have been attached.  Maxim of course will correct me if 
I'm wrong.

Hrm...  I think you're right about that.  Let me look closer at it.

Josh, you are correct.  I can see which node is connected where by 
it's position in the !plug/subordinates block.

Maxim...  I've created all the plugs I need to process each value 
in a font object and they are working beautifully but I'm having 
trouble figuring out what the master !font node should look like. 
 I need to be able to copy changes from each of the nodes handling 
the individual values into an object that I can pass to VID.  Do 
you have any words of wisdom to share on this? ;-)

Ah, what wonders a few hours of rest can work.  I just need to produce 
a plug that takes a series of inputs and converts it into an object. 
 I was overcomplicating things (again...)  When I get back from work 
I'll take another shot at it and this time I think I'll go with a 
dialected approach.

yep ammon that is it.